Re: [PATCH net-next 0/6] net: stmmac: yet more cleanups

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Sep 23, 2025 at 12:25:30PM +0100, Russell King (Oracle) wrote:
> Building on the previous cleanup series, this cleans up yet more stmmac
> code.
> 
> - Move stmmac_bus_clks_config() into stmmac_platform() which is where
>   its onlny user is.
> 
> - Move the xpcs Clause 73 test into stmmac_init_phy(), resulting in
>   simpler code in __stmmac_open().
> 
> - Move "can't attach PHY" error message into stmmac_init_phy().
> 
> We then start moving stuff out of __stmac_open() into stmmac_open()
> (and correspondingly __stmmac_release() into stmmac_release()) which
> is not necessary when re-initialising the interface on e.g. MTU change.
> 
> - Move initialisation of tx_lpi_timer
> - Move PHY attachment/detachment
> - Move PHY error message into stmmac_init_phy()
> 
> Finally, simplfy the paths in stmmac_init_phy().
> 
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h       |   1 -
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 111 ++++++++-------------
>  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  32 ++++++
>  3 files changed, 73 insertions(+), 71 deletions(-)

Should've added: tested on nVidia Jetson Xavier NX.

However, observed a failure changing the MTU with the link down - our
old friend, failure to complete the DMA reset.

Once that's been triggered, taking the interface down or changing the
MTU again results in more problems, with the thread spinning in
napi_disable_locked() with RTNL held (as we effectively end up calling
napi_disable() twice on the same napi struct.)

This basically makes the platforms networking unusable - and needs to
be hard-reset.

These issues pre-exist all my cleanups.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!