| Message ID | Z9ySeo61VYTClIJJ@shell.armlinux.org.uk (mailing list archive) |
|---|---|
| Headers | show |
| Series | net: improve stmmac resume rx clocking | expand |
Hello: This series was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Thu, 20 Mar 2025 22:11:06 +0000 you wrote: > Hi, > > stmmac has had a long history of problems with resuming, illustrated by > reset failure due to the receive clock not running. > > Several attempts have been attempted over the years to address this > issue, such as moving phylink_start() (now phylink_resume()) super > early in stmmac_resume() in commit 90702dcd19c0 ("net: stmmac: fix MAC > not working when system resume back with WoL a ctive.") However, this > has the downside that stmmac_mac_link_up() can (and demonstrably is) > called before or during the driver initialisation in another thread. > This can cause issues as packets could begin to be queued, and the > transmit/receive enable bits will be set before any initialisation has > been done. > > [...] Here is the summary with links: - [net-next,1/5] net: phylink: add phylink_prepare_resume() https://git.kernel.org/netdev/net-next/c/367f1854d442 - [net-next,2/5] net: stmmac: address non-LPI resume failures properly https://git.kernel.org/netdev/net-next/c/ef43e5132895 - [net-next,3/5] net: stmmac: socfpga: remove phy_resume() call https://git.kernel.org/netdev/net-next/c/366aeeba7908 - [net-next,4/5] net: phylink: add functions to block/unblock rx clock stop https://git.kernel.org/netdev/net-next/c/ddf4bd3f7384 - [net-next,5/5] net: stmmac: block PHY RXC clock-stop https://git.kernel.org/netdev/net-next/c/dd557266cf5f You are awesome, thank you!
Hi, stmmac has had a long history of problems with resuming, illustrated by reset failure due to the receive clock not running. Several attempts have been attempted over the years to address this issue, such as moving phylink_start() (now phylink_resume()) super early in stmmac_resume() in commit 90702dcd19c0 ("net: stmmac: fix MAC not working when system resume back with WoL a ctive.") However, this has the downside that stmmac_mac_link_up() can (and demonstrably is) called before or during the driver initialisation in another thread. This can cause issues as packets could begin to be queued, and the transmit/receive enable bits will be set before any initialisation has been done. Another attempt is used by dwmac-socfpga.c in commit 2d871aa07136 ("net: stmmac: add platform init/exit for Altera's ARM socfpga") which pre-dates the above commit. Neither of these two approaches consider the effect of EEE with a PHY that supports receive clock-stop and has that feature enabled (which the stmmac driver does enable). If the link is up, then there is the possibility for the receive path to be in low-power mode, and the PHY may stop its receive clock. This series addresses these issues by (each is not necessarily a separate patch): 1) introducing phylink_prepare_resume(), which can be used by MAC drivers to ensure that the PHY is resumed prior to doing any re-initialisation work. This call is added to stmmac_resume(). 2) moving phylink_resume() after all re-initialisation has completed, thereby ensuring that the hardware is ready to be enabled for packet reception/transmission. 3) with (1) and (2) addressed, the need for socfpga to have a private work-around is no longer necessary, so it is removed. 4) introducing phylink functions to block/unblock the receive clock- stop at the PHY. As these require PHY access over the MDIO bus, they can sleep, so are not suitable for atomic access. 5) the stmmac hardware requires the receive clock to be running for reset to complete. Depending on synthesis options, this requirement may also extend to writing various registers as well, e.g. setting the MAC address, writing some of the vlan registers, etc. Full details are in the databook. We add blocking/unblocking of the PHY receive clock-stop around parts of the main stmmac driver where we have a context that we can sleep. These are wrapped with the new phylink functions. However, depending on synthesis options, there could be other places where the net core calls the driver with a BH-disabled context where we can't sleep, and thus can't block the PHY from disabling its receive clock. These are documented with FIXME comments. Given the last paragraph above, I am wondering whether a better approach would be to ensure that receive clock-stop is always disabled at the PHY with stmmac. From what I can see, implementations do not document to this level of detail, which makes it difficult to tell which registers require the receive clock to be running to behave correctly. This patch series has been tested on the Tegra194 Jetson Xavier NX board kindly donated by NVidia, with two additional patches that are pending in patchwork - the first is required to have EEE's LPI mode passed through to the MAC on this platform to allow testing under PHY clock-stop scenarios. The second is a bug fix for PHYLIB and makes "eee off" functional, but should not affect this series. All patches on top of net-next commit f749448ce9f1 ("Merge branch 'net-mlx5-hw-steering-cleanups'") https://patchwork.kernel.org/project/netdevbpf/patch/E1ttnHW-00785s-Uq@rmk-PC.armlinux.org.uk/ https://patchwork.kernel.org/project/netdevbpf/patch/E1ttmWN-0077Mb-Q6@rmk-PC.armlinux.org.uk/ .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 18 ----- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 46 ++++++++++-- drivers/net/phy/phylink.c | 84 ++++++++++++++++++++++ include/linux/phylink.h | 4 ++ 4 files changed, 129 insertions(+), 23 deletions(-)