| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Feb 2023 10:27:06 +0000
From: Clark Wang <xiaoning.wang@....com>
To: Russell King <linux@...linux.org.uk>,
Paolo Abeni <pabeni@...hat.com>
CC: "peppe.cavallaro@...com" <peppe.cavallaro@...com>,
"alexandre.torgue@...s.st.com" <alexandre.torgue@...s.st.com>,
"joabreu@...opsys.com" <joabreu@...opsys.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>,
"andrew@...n.ch" <andrew@...n.ch>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-stm32@...md-mailman.stormreply.com"
<linux-stm32@...md-mailman.stormreply.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH V3 1/2] net: phylink: add a function to resume phy alone
to fix resume issue with WoL enabled
> -----Original Message-----
> From: Russell King <linux@...linux.org.uk>
> Sent: 2023年2月23日 18:22
> To: Paolo Abeni <pabeni@...hat.com>
> Cc: Clark Wang <xiaoning.wang@....com>; peppe.cavallaro@...com;
> alexandre.torgue@...s.st.com; joabreu@...opsys.com;
> davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> mcoquelin.stm32@...il.com; andrew@...n.ch; hkallweit1@...il.com;
> netdev@...r.kernel.org; linux-stm32@...md-mailman.stormreply.com;
> linux-arm-kernel@...ts.infradead.org; linux-kernel@...r.kernel.org;
> dl-linux-imx <linux-imx@....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@....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@...el.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!
Powered by blists - more mailing lists