| Message ID | 20230314131443.46342-1-wsa+renesas@sang-engineering.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: set 'mac_managed_pm' at probe time | expand |
On Tue, Mar 14, 2023 at 02:14:38PM +0100, Wolfram Sang wrote: > When suspending/resuming an interface which was not up, we saw mdiobus > related PM handling despite 'mac_managed_pm' being set for RAVB/SH_ETH. > Heiner kindly suggested the fix to set this flag at probe time, not at > init/open time. I implemented his suggestion and it works fine on these > two Renesas drivers. These are patches 1+2. > > I then looked which other drivers could be affected by the same problem. > I could only identify two where I am quite sure. Because I don't have > any HW, I opted to at least add a FIXME and send this out as patches > 3+4. Ideally, they will never need to go upstream because the relevant > people will see their patch and do something like I did for patches 1+2. > > Looking forward to comments. Thanks and happy hacking! > > > Wolfram Sang (4): > ravb: avoid PHY being resumed when interface is not up > sh_eth: avoid PHY being resumed when interface is not up > fec: add FIXME to move 'mac_managed_pm' to probe > smsc911x: add FIXME to move 'mac_managed_pm' to probe > > drivers/net/ethernet/freescale/fec_main.c | 1 + > drivers/net/ethernet/renesas/ravb_main.c | 12 ++++++++++-- > drivers/net/ethernet/renesas/sh_eth.c | 12 ++++++++++-- > drivers/net/ethernet/smsc/smsc911x.c | 1 + > 4 files changed, 22 insertions(+), 4 deletions(-) > > -- > 2.30.2 > Unfortunately, I wasn't able to check the series in terms of content, but I have no objections to the logic and coding style. For the series. Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Thanks, Michal
On Tue, Mar 14, 2023 at 02:14:38PM +0100, Wolfram Sang wrote: > When suspending/resuming an interface which was not up, we saw mdiobus > related PM handling despite 'mac_managed_pm' being set for RAVB/SH_ETH. > Heiner kindly suggested the fix to set this flag at probe time, not at > init/open time. I implemented his suggestion and it works fine on these > two Renesas drivers. These are patches 1+2. > > I then looked which other drivers could be affected by the same problem. > I could only identify two where I am quite sure. Because I don't have > any HW, I opted to at least add a FIXME and send this out as patches > 3+4. Ideally, they will never need to go upstream because the relevant > people will see their patch and do something like I did for patches 1+2. > > Looking forward to comments. Thanks and happy hacking! Hi Wolfram, an initial comment is, and I know this is a bit of a pain, that 'net' and 'net-next' patches need to be split into separate serries. And if there are dependencies, the 'net' series should go first, and then the 'net-next' series should go out once the 'net' patches have been accepted and 'net' has been merged into 'net-next', which I believe occurs after Linus has pulled the weekly 'net' pull request, which typically occurs on Thursdays. > Wolfram Sang (4): > ravb: avoid PHY being resumed when interface is not up > sh_eth: avoid PHY being resumed when interface is not up > fec: add FIXME to move 'mac_managed_pm' to probe > smsc911x: add FIXME to move 'mac_managed_pm' to probe > > drivers/net/ethernet/freescale/fec_main.c | 1 + > drivers/net/ethernet/renesas/ravb_main.c | 12 ++++++++++-- > drivers/net/ethernet/renesas/sh_eth.c | 12 ++++++++++-- > drivers/net/ethernet/smsc/smsc911x.c | 1 + > 4 files changed, 22 insertions(+), 4 deletions(-) > > -- > 2.30.2 >
Hi Simon! > an initial comment is, and I know this is a bit of a pain, > that 'net' and 'net-next' patches need to be split into separate serries. Thanks for the heads up. I will refactor the series. First a part which shall go into "net" and I will make the second part RFC with more explanations how to reproduce the issue. All the best, Wolfram