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 <redacted>
---
Changes for V2: Actually make sure it compiles this time.
---
drivers/net/phy/micrel.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
@@ -447,6 +447,22 @@ static int ksz9031_center_flp_timing(struct phy_device *phydev)returngenphy_restart_aneg(phydev);}+staticintksz9031_resume(structphy_device*phydev)+{+intresult;++result=genphy_resume(phydev);++if(result)+returnresult;++/* This phy will reset interrupt enables when leaving power down */+if(PHY_INTERRUPT_ENABLED&phydev->interrupts)+result=kszphy_config_intr(phydev);++returnresult;+}+staticintksz9031_config_init(structphy_device*phydev){conststructdevice*dev=&phydev->dev;
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 <redacted>
@@ -447,6 +447,22 @@ static int ksz9031_center_flp_timing(struct phy_device *phydev)returngenphy_restart_aneg(phydev);}+staticintksz9031_resume(structphy_device*phydev)+{+intresult;++result=genphy_resume(phydev);++if(result)+returnresult;++/* This phy will reset interrupt enables when leaving power down */+if(PHY_INTERRUPT_ENABLED&phydev->interrupts)+result=kszphy_config_intr(phydev);++returnresult;+}+staticintksz9031_config_init(structphy_device*phydev){conststructdevice*dev=&phydev->dev;
From: Sergei Shtylyov <hidden> Date: 2015-07-30 18:01:05
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 <redacted>
---
Changes for V2: Actually make sure it compiles this time.
@@ -447,6 +447,22 @@ static int ksz9031_center_flp_timing(struct phy_device *phydev)returngenphy_restart_aneg(phydev);}+staticintksz9031_resume(structphy_device*phydev)+{+intresult;++result=genphy_resume(phydev);+
I don't think empty line is needed here. Sorry for missing it in the first posting...
quoted hunk
+ 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;+}+
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.
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.
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?
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.