Re: [PATCH net-next 9/9] net: stmmac: convert to phylink managed EEE support
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
Date: 2025-02-19 19:27:32
Also in:
linux-arm-kernel, linux-tegra
On Wed, Feb 19, 2025 at 05:52:34PM +0000, Jon Hunter wrote:
On 19/02/2025 15:36, Russell King (Oracle) wrote:quoted
So clearly the phylink resolver is racing with the rest of the stmmac resume path - which doesn't surprise me in the least. I believe I raised the fact that calling phylink_resume() before the hardware was ready to handle link-up is a bad idea precisely because of races like this. The reason stmmac does this is because of it's quirk that it needs the receive clock from the PHY in order for stmmac_reset() to work.I do see the reset fail infrequently on previous kernels with this device and when it does I see these messages ... dwc-eth-dwmac 2490000.ethernet: Failed to reset the dma dwc-eth-dwmac 2490000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed
I wonder whether it's also racing with phylib, but phylink_resume() calling phylink_start() going in to call phy_start() is all synchronous. That causes __phy_resume() to be called. Which PHY device/driver is being used?
quoted
So, my preference would be to move phylink_resume() later, removing the race condition. If there's any regressions, then we need to _properly_ solve them by ensuring that the PHY keeps the RX clock running by honouring PHY_F_RXC_ALWAYS_ON. That's going to need everyone to test their stmmac platforms to find all the cases that need fixing...Thanks for the in-depth analysis and feedback. We have 3 SoCs that use this driver and so I will do some testing with this change on all of them.
Thanks! -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!