Re: [PATCH net] net: stmmac: resume PHY before reopening the interface on MTU change
From: Stefan Agner <stefan@agner.ch>
Date: 2026-07-07 18:57:41
Also in:
linux-arm-kernel, regressions
On 2026-07-07 19:20, Jakub Raczynski wrote:
On Tue, Jul 07, 2026 at 06:21:46PM +0200, Stefan Agner wrote:quoted
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c@@ -5884,6 +5884,15 @@ __stmmac_release(dev); + /* phylink_stop() in __stmmac_release() suspends the PHY. + * IEEE 802.3 allows PHYs to stop their receive clock while + * powered down, but the DMA software reset performed by + * stmmac_hw_setup() requires a running receive clock. + * Resume the PHY, as on system resume, to ensure its clocks + * are running before reopening the interface. + */ + phylink_prepare_resume(priv->phylink);Does it work without warnings? Nothing in dmesg?
With this patch applied, this is the dmesg log on MTU change: [ 56.761175] rk_gmac-dwmac fe010000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 56.762769] rk_gmac-dwmac fe010000.ethernet end0: Link is Down [ 56.801327] dwmac4: Master AXI performs any burst length [ 56.801368] rk_gmac-dwmac fe010000.ethernet end0: No Safety Features support found [ 56.801409] rk_gmac-dwmac fe010000.ethernet end0: IEEE 1588-2008 Advanced Timestamp supported [ 56.801780] rk_gmac-dwmac fe010000.ethernet end0: registered PTP clock [ 56.801804] rk_gmac-dwmac fe010000.ethernet end0: configuring for phy/rgmii link mode [ 61.032985] rk_gmac-dwmac fe010000.ethernet end0: Link is Up - 1Gbps/Full - flow control off
phylink_prepare_resume() does have ASSERT_RTNL() which is not called anywhere.
I am not very familiar with the codebase, but Fable states:
RTNL is held here: ndo_change_mtu is invoked from netif_set_mtu_ext(), which calls netdev_ops_assert_locked() — for a driver without instance locking such as stmmac that is ASSERT_RTNL() — right before calling the driver op.
What I can definitely confirm is that without this patch applied, a MTU change does not succeed, with it applied MTU change works and the network interface remains functional. -- Stefan