Messages in this thread | | | From | Clark Wang <> | Subject | RE: [PATCH 1/2] net: phylink: add sync flag mac_ready to fix resume issue with WoL enabled | Date | Wed, 30 Nov 2022 12:00:55 +0000 |
| |
> -----Original Message----- > From: Russell King <linux@armlinux.org.uk> > Sent: 2022年11月30日 19:51 > To: Clark Wang <xiaoning.wang@nxp.com> > Cc: peppe.cavallaro@st.com; alexandre.torgue@foss.st.com; > joabreu@synopsys.com; davem@davemloft.net; edumazet@google.com; > kuba@kernel.org; pabeni@redhat.com; mcoquelin.stm32@gmail.com; > andrew@lunn.ch; hkallweit1@gmail.com; netdev@vger.kernel.org; > linux-stm32@st-md-mailman.stormreply.com; > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/2] net: phylink: add sync flag mac_ready to fix resume > issue with WoL enabled > > On Wed, Nov 30, 2022 at 11:32:09AM +0000, Clark Wang wrote: > > Hi Russell, > > > > > -----Original Message----- > > > From: Russell King <linux@armlinux.org.uk> > > > Sent: 2022年11月30日 19:24 > > > To: Clark Wang <xiaoning.wang@nxp.com> > > > Cc: peppe.cavallaro@st.com; alexandre.torgue@foss.st.com; > > > joabreu@synopsys.com; davem@davemloft.net; > edumazet@google.com; > > > kuba@kernel.org; pabeni@redhat.com; mcoquelin.stm32@gmail.com; > > > andrew@lunn.ch; hkallweit1@gmail.com; netdev@vger.kernel.org; > > > linux-stm32@st-md-mailman.stormreply.com; > > > linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org > > > Subject: Re: [PATCH 1/2] net: phylink: add sync flag mac_ready to fix > resume > > > issue with WoL enabled > > > > > > On Wed, Nov 30, 2022 at 07:11:47PM +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(). stmmac_core_init() is called in function > > > > stmmac_hw_setup(), > > > > > > ... and that is where the problem is. Don't call phylink_resume() before > your > > > hardware is ready to see a link-up event. > > > > Thank you very much for your reply! > > > > You are right. > > > > However, stmmac requires RXC to have a clock input when performing a > reset(in stmmac_hw_setup()). On our board, RXC is provided by the phy. > > > > In WoL mode, this is not a problem, because the phy will not be down > when suspend. RXC will keep output. But in normal suspend(without WoL), > the phy will be down, which does not guarantee the output of the RXC of the > phy. Therefore, the previous code will call phylink_resume() before > stmmac_hw_setup(). > > I think we need phylink_phy_resume() which stmmac can use to resume the > PHY without resuming phylink, assuming that will output the RXC. Which > PHY driver(s) are used with stmmac?
Yes, that will be a better way! For now, we use AR8031 in drivers/net/phy/at803x.c and RTL8211F/RTL8211F-VD in drivers/net/phy/realtek.c with stmmac.
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%7Cxia > oning.wang%40nxp.com%7C9b3a5389973b48963ee708dad2c924a3%7C686 > ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638054058591085448%7C > Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0qb%2F > NpZUeI42SGekT488Lob9aQ6d2EB4xV944330QkI%3D&reserved=0 > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
| |