[PATCH net v2] net: stmmac: resume PHY before hardware setup when opening the interface

Alexander Stein alexander.stein at ew.tq-group.com
Wed Jul 8 01:00:55 PDT 2026


Hi Stefan,

thanks for the patch.

Am Dienstag, 7. Juli 2026, 21:54:25 CEST schrieb Stefan Agner:
> Since the referenced commit, changing the MTU on a running interface no
> longer disconnects and reconnects the PHY; __stmmac_release() merely
> stops phylink, which also suspends the PHY (BMCR power-down) when WoL
> is not enabled. __stmmac_open() then performs the DMA software reset in
> stmmac_hw_setup() before phylink_start() resumes the PHY again.
> 
> IEEE 802.3 22.2.4.1.5 allows a PHY to stop its receive clock while
> powered down, and stmmac requires a running receive clock for the DMA
> software reset to complete (the phylink config sets mac_requires_rxc).
> On such setups, e.g. the RK3566-based Home Assistant Green with an
> RTL8211F-VD PHY in RGMII mode, any runtime MTU change now times out and
> leaves the interface dead:
> 
>   rk_gmac-dwmac fe010000.ethernet end0: Failed to reset the dma
>   rk_gmac-dwmac fe010000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed
>   rk_gmac-dwmac fe010000.ethernet end0: __stmmac_open: Hw setup failed
>   rk_gmac-dwmac fe010000.ethernet end0: failed reopening the interface after MTU change
> 
> In the field this is triggered by NetworkManager applying an MTU while
> activating the connection, breaking networking entirely.
> 
> Resume the PHY in __stmmac_open() before the hardware setup, making it
> the counterpart of the phylink_stop() in __stmmac_release(), like
> stmmac_resume() already does for the same reason. phylink_start() also
> resumes the PHY, but only after stmmac_hw_setup(), and it cannot be
> moved before the hardware setup since it may bring the link up
> immediately from a workqueue, racing with the initialization (see the
> comment in stmmac_resume()). For the regular ndo_open path the PHY has
> just been attached and is not suspended, in which case
> phylink_prepare_resume() does nothing.
> 
> Fixes: db299a0c09e9 ("net: stmmac: move PHY handling out of __stmmac_open()/release()")
> Link: https://github.com/home-assistant/operating-system/issues/4858
> Signed-off-by: Stefan Agner <stefan at agner.ch>

FWIW imx8mp based platforms (TQMa8MPxL in my case) are also affected, see [1].

This patch fixes the problem here as well, so:
Tested-by: Alexander Stein <alexander.stein at ew.tq-group.com>

[1] https://lore.kernel.org/all/8409022.LvFx2qVVIh@steina-w/

> ---
> Changes in v2:
> - Move the PHY resume from stmmac_change_mtu() into __stmmac_open() so
>   that it also counters the PHY suspend caused by __stmmac_release()
>   (suggested by Andrew Lunn), placed before stmmac_reset_queues_param()
>   to match the ordering used in stmmac_resume()
> 
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> 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
> @@ -4147,6 +4147,15 @@
>  			dma_conf->tx_queue[i].tbs = priv->dma_conf.tx_queue[i].tbs;
>  	memcpy(&priv->dma_conf, dma_conf, sizeof(*dma_conf));
>  
> +	/* The PHY is suspended when the interface is reopened without
> +	 * disconnecting the PHY, e.g. on MTU change. IEEE 802.3 allows PHYs
> +	 * to stop their receive clock while powered down, but the DMA
> +	 * software reset in stmmac_hw_setup() requires a running receive
> +	 * clock, and phylink_start() below resumes the PHY only after the
> +	 * hardware setup. Resume a suspended PHY here first.
> +	 */
> +	phylink_prepare_resume(priv->phylink);
> +
>  	stmmac_reset_queues_param(priv);
>  
>  	ret = stmmac_hw_setup(dev);
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/





More information about the linux-arm-kernel mailing list