[PATCH V3 1/2] net: phylink: add a function to resume phy alone to fix resume issue with WoL enabled
Clark Wang
xiaoning.wang at nxp.com
Thu Feb 23 02:27:06 PST 2023
> -----Original Message-----
> From: Russell King <linux at armlinux.org.uk>
> Sent: 2023年2月23日 18:22
> To: Paolo Abeni <pabeni at redhat.com>
> Cc: Clark Wang <xiaoning.wang at nxp.com>; peppe.cavallaro at st.com;
> alexandre.torgue at foss.st.com; joabreu at synopsys.com;
> davem at davemloft.net; edumazet at google.com; kuba at kernel.org;
> mcoquelin.stm32 at gmail.com; andrew at lunn.ch; hkallweit1 at gmail.com;
> netdev at vger.kernel.org; linux-stm32 at st-md-mailman.stormreply.com;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> dl-linux-imx <linux-imx at nxp.com>
> Subject: Re: [PATCH V3 1/2] net: phylink: add a function to resume phy alone
> to fix resume issue with WoL enabled
>
> On Thu, Feb 23, 2023 at 11:09:04AM +0100, Paolo Abeni wrote:
> > On Thu, 2023-02-02 at 16:15 +0800, Clark Wang wrote:
> > > Issue we met:
> > > On some platforms, mac cannot work after resumed from the suspend
> with WoL
> > > enabled.
> > >
> > > The cause of the issue:
> > > 1. phylink_resolve() is in a workqueue which will not be executed
> immediately.
> > > This is the call sequence:
> > >
> phylink_resolve()->phylink_link_up()->pl->mac_ops->mac_link_up()
> > > For stmmac driver, mac_link_up() will set the correct speed/duplex...
> > > values which are from link_state.
> > > 2. In stmmac_resume(), it will call stmmac_hw_setup() after called the
> > > phylink_resume(), because mac need phy rx_clk to do the reset.
> > > stmmac_core_init() is called in function stmmac_hw_setup(), which
> will
> > > reset the mac and set the speed/duplex... to default value.
> > > Conclusion: Because phylink_resolve() cannot determine when it is called,
> it
> > > cannot be guaranteed to be called after
> stmmac_core_init().
> > > Once stmmac_core_init() is called after phylink_resolve(),
> > > the mac will be misconfigured and cannot be used.
> > >
> > > In order to avoid this problem, add a function called
> phylink_phy_resume()
> > > to resume phy separately. This eliminates the need to call
> phylink_resume()
> > > before stmmac_hw_setup().
> > >
> > > Add another judgement before called phy_start() in phylink_start(). This
> way
> > > phy_start() will not be called multiple times when resumes. At the same
> time,
> > > it may not affect other drivers that do not use phylink_phy_resume().
> > >
> > > Signed-off-by: Clark Wang <xiaoning.wang at nxp.com>
> > > ---
> > > V2 change:
> > > - add mac_resume_phy_separately flag to struct phylink to mark if the
> mac
> > > driver uses the phylink_phy_resume() first.
> > > V3 change:
> > > - add brace to avoid ambiguous 'else'
> > > Reported-by: kernel test robot <lkp at intel.com>
> > > ---
> > > drivers/net/phy/phylink.c | 32 ++++++++++++++++++++++++++++++--
> > > include/linux/phylink.h | 1 +
> > > 2 files changed, 31 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > > index 319790221d7f..c2fe66f0b78f 100644
> > > --- a/drivers/net/phy/phylink.c
> > > +++ b/drivers/net/phy/phylink.c
> > > @@ -80,6 +80,8 @@ struct phylink {
> > > DECLARE_PHY_INTERFACE_MASK(sfp_interfaces);
> > > __ETHTOOL_DECLARE_LINK_MODE_MASK(sfp_support);
> > > u8 sfp_port;
> > > +
> > > + bool mac_resume_phy_separately;
> > > };
> > >
> > > #define phylink_printk(level, pl, fmt, ...) \
> > > @@ -1509,6 +1511,7 @@ struct phylink *phylink_create(struct
> phylink_config *config,
> > > return ERR_PTR(-EINVAL);
> > > }
> > >
> > > + pl->mac_resume_phy_separately = false;
> > > pl->using_mac_select_pcs = using_mac_select_pcs;
> > > pl->phy_state.interface = iface;
> > > pl->link_interface = iface;
> > > @@ -1943,8 +1946,12 @@ void phylink_start(struct phylink *pl)
> > > }
> > > if (poll)
> > > mod_timer(&pl->link_poll, jiffies + HZ);
> > > - if (pl->phydev)
> > > - phy_start(pl->phydev);
> > > + if (pl->phydev) {
> > > + if (!pl->mac_resume_phy_separately)
> > > + phy_start(pl->phydev);
> > > + else
> > > + pl->mac_resume_phy_separately = false;
> > > + }
> > > if (pl->sfp_bus)
> > > sfp_upstream_start(pl->sfp_bus);
> > > }
> > > @@ -2024,6 +2031,27 @@ void phylink_suspend(struct phylink *pl, bool
> mac_wol)
> > > }
> > > EXPORT_SYMBOL_GPL(phylink_suspend);
> > >
> > > +/**
> > > + * phylink_phy_resume() - resume phy alone
> > > + * @pl: a pointer to a &struct phylink returned from phylink_create()
> > > + *
> > > + * In the MAC driver using phylink, if the MAC needs the clock of the phy
> > > + * when it resumes, can call this function to resume the phy separately.
> > > + * Then proceed to MAC resume operations.
> > > + */
> > > +void phylink_phy_resume(struct phylink *pl)
> > > +{
> > > + ASSERT_RTNL();
> > > +
> > > + if (!test_bit(PHYLINK_DISABLE_MAC_WOL,
> &pl->phylink_disable_state)
> > > + && pl->phydev) {
> > > + phy_start(pl->phydev);
> > > + pl->mac_resume_phy_separately = true;
> > > + }
> > > +
> >
> > Minor nit: the empty line here is not needed.
>
> The author appears to have become non-responsive after sending half of
> the two patch series, and hasn't addressed previous feedback.
>
> In any case, someone else was also having similar issues with stmmac,
> and proposing different patches, so I've requested that they work
> together to solve what looks like one common problem, instead of us
> ending up with two patch series potentially addressing that same
> issue.
Hi Russel,
I have sent the V4 patch set yesterday.
You can check it from: https://lore.kernel.org/linux-arm-kernel/20230222092636.1984847-2-xiaoning.wang@nxp.com/T/
Thanks.
Best Regards,
Clark Wang
>
> --
> RMK's Patch system:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .armlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=05%7C01%7Cxiaoning.
> wang%40nxp.com%7C675fb3cfa68f4424734008db1587c30d%7C686ea1d3b
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C638127445057658328%7CUnkno
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k3ZozZTq%2BRIik67
> %2FQFCAEQ7IDb%2FRAPJBXbigLgtbsSU%3D&reserved=0
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
More information about the linux-arm-kernel
mailing list