The ksz9031 has a behavior where it will clear the interrupt enable bits
when leaving power down. To work around this, make sure the interrupt
bits are in the state they are expected to be when resuming.
Signed-off-by: Nathan Sullivan <[email protected]>
---
Changes for V2: Actually make sure it compiles this time.
---
drivers/net/phy/micrel.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 499185e..9774582 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -447,6 +447,22 @@ static int ksz9031_center_flp_timing(struct phy_device *phydev)
return genphy_restart_aneg(phydev);
}
+static int ksz9031_resume(struct phy_device *phydev)
+{
+ int result;
+
+ result = genphy_resume(phydev);
+
+ if (result)
+ return result;
+
+ /* This phy will reset interrupt enables when leaving power down */
+ if (PHY_INTERRUPT_ENABLED & phydev->interrupts)
+ result = kszphy_config_intr(phydev);
+
+ return result;
+}
+
static int ksz9031_config_init(struct phy_device *phydev)
{
const struct device *dev = &phydev->dev;
@@ -776,7 +792,7 @@ static struct phy_driver ksphy_driver[] = {
.ack_interrupt = kszphy_ack_interrupt,
.config_intr = kszphy_config_intr,
.suspend = genphy_suspend,
- .resume = genphy_resume,
+ .resume = ksz9031_resume,
.driver = { .owner = THIS_MODULE, },
}, {
.phy_id = PHY_ID_KSZ8873MLL,
--
1.7.10.4
On 30/07/15 08:15, Nathan Sullivan wrote:
> The ksz9031 has a behavior where it will clear the interrupt enable bits
> when leaving power down. To work around this, make sure the interrupt
> bits are in the state they are expected to be when resuming.
>
> Signed-off-by: Nathan Sullivan <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
> ---
>
> Changes for V2: Actually make sure it compiles this time.
>
> ---
> drivers/net/phy/micrel.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 499185e..9774582 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -447,6 +447,22 @@ static int ksz9031_center_flp_timing(struct phy_device *phydev)
> return genphy_restart_aneg(phydev);
> }
>
> +static int ksz9031_resume(struct phy_device *phydev)
> +{
> + int result;
> +
> + result = genphy_resume(phydev);
> +
> + if (result)
> + return result;
> +
> + /* This phy will reset interrupt enables when leaving power down */
> + if (PHY_INTERRUPT_ENABLED & phydev->interrupts)
> + result = kszphy_config_intr(phydev);
> +
> + return result;
> +}
> +
> static int ksz9031_config_init(struct phy_device *phydev)
> {
> const struct device *dev = &phydev->dev;
> @@ -776,7 +792,7 @@ static struct phy_driver ksphy_driver[] = {
> .ack_interrupt = kszphy_ack_interrupt,
> .config_intr = kszphy_config_intr,
> .suspend = genphy_suspend,
> - .resume = genphy_resume,
> + .resume = ksz9031_resume,
> .driver = { .owner = THIS_MODULE, },
> }, {
> .phy_id = PHY_ID_KSZ8873MLL,
>
--
Florian
From: Nathan Sullivan <[email protected]>
Date: Thu, 30 Jul 2015 10:15:48 -0500
> Changes for V2: Actually make sure it compiles this time.
If V1 didn't compile, even for you, then I have a big problem.
And that problem is that you didn't test this change at all.
Hello.
On 07/30/2015 06:15 PM, Nathan Sullivan wrote:
> The ksz9031 has a behavior where it will clear the interrupt enable bits
> when leaving power down. To work around this, make sure the interrupt
> bits are in the state they are expected to be when resuming.
> Signed-off-by: Nathan Sullivan <[email protected]>
> ---
> Changes for V2: Actually make sure it compiles this time.
> ---
> drivers/net/phy/micrel.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 499185e..9774582 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -447,6 +447,22 @@ static int ksz9031_center_flp_timing(struct phy_device *phydev)
> return genphy_restart_aneg(phydev);
> }
>
> +static int ksz9031_resume(struct phy_device *phydev)
> +{
> + int result;
> +
> + result = genphy_resume(phydev);
> +
I don't think empty line is needed here. Sorry for missing it in the first
posting...
> + if (result)
> + return result;
> +
> + /* This phy will reset interrupt enables when leaving power down */
> + if (PHY_INTERRUPT_ENABLED & phydev->interrupts)
> + result = kszphy_config_intr(phydev);
> +
> + return result;
> +}
> +
[...]
WBR, Sergei
On Thu, Jul 30, 2015 at 10:00:34AM -0700, David Miller wrote:
> From: Nathan Sullivan <[email protected]>
> Date: Thu, 30 Jul 2015 10:15:48 -0500
>
> > Changes for V2: Actually make sure it compiles this time.
>
> If V1 didn't compile, even for you, then I have a big problem.
>
> And that problem is that you didn't test this change at all.
Sorry about that, I have tested it against 3.14, which is why I had
the older interrupt function in v1. On HEAD, the phy no longer
suspends when ethernet goes down on our hardware - I'm still working
on figuring out why. I'm also surprised no one noticed this behavior
before I did, but if the phy never goes into suspend you wouldn't.
From: Nathan Sullivan <[email protected]>
Date: Thu, 30 Jul 2015 18:09:05 -0500
> On Thu, Jul 30, 2015 at 10:00:34AM -0700, David Miller wrote:
>> From: Nathan Sullivan <[email protected]>
>> Date: Thu, 30 Jul 2015 10:15:48 -0500
>>
>> > Changes for V2: Actually make sure it compiles this time.
>>
>> If V1 didn't compile, even for you, then I have a big problem.
>>
>> And that problem is that you didn't test this change at all.
>
> Sorry about that, I have tested it against 3.14, which is why I had
> the older interrupt function in v1. On HEAD, the phy no longer
> suspends when ethernet goes down on our hardware - I'm still working
> on figuring out why. I'm also surprised no one noticed this behavior
> before I did, but if the phy never goes into suspend you wouldn't.
I think you should sort out the PHY suspending issue before we move
forward with this patch.
On Fri, Jul 31, 2015 at 12:22:04AM -0700, David Miller wrote:
> From: Nathan Sullivan <[email protected]>
> Date: Thu, 30 Jul 2015 18:09:05 -0500
>
> > On Thu, Jul 30, 2015 at 10:00:34AM -0700, David Miller wrote:
> >> From: Nathan Sullivan <[email protected]>
> >> Date: Thu, 30 Jul 2015 10:15:48 -0500
> >>
> >> > Changes for V2: Actually make sure it compiles this time.
> >>
> >> If V1 didn't compile, even for you, then I have a big problem.
> >>
> >> And that problem is that you didn't test this change at all.
> >
> > Sorry about that, I have tested it against 3.14, which is why I had
> > the older interrupt function in v1. On HEAD, the phy no longer
> > suspends when ethernet goes down on our hardware - I'm still working
> > on figuring out why. I'm also surprised no one noticed this behavior
> > before I did, but if the phy never goes into suspend you wouldn't.
>
> I think you should sort out the PHY suspending issue before we move
> forward with this patch.
I believe I found the issue, we are using this PHY with cadence macb as
the MAC. The driver currently turns off the management port in
macb_reset_hw, which we have stopped with a local change since our hardware
typically has multiple phys on one mdio bus. That also prevents phy suspend
from working correctly, since the bus goes down before the phy state machine
can stop the phy.
In our local patch, we have macb_reset_hw keep the mdio bus on if it's on
already. Does that sound like an acceptable fix to you?
From: Nathan Sullivan <[email protected]>
Date: Fri, 31 Jul 2015 09:27:06 -0500
> I believe I found the issue, we are using this PHY with cadence macb as
> the MAC. The driver currently turns off the management port in
> macb_reset_hw, which we have stopped with a local change since our hardware
> typically has multiple phys on one mdio bus. That also prevents phy suspend
> from working correctly, since the bus goes down before the phy state machine
> can stop the phy.
>
> In our local patch, we have macb_reset_hw keep the mdio bus on if it's on
> already. Does that sound like an acceptable fix to you?
Then you don't need this patch at all if your hardware configuration
in question will not suspend the PHY device.
Can you see how rediculous this situation looks to me?
You can't even test this change on the hardware you are using.