[PATCH] arm64: dts: imx8mp-debix-model-a: Disable EEE for 1000T

[Russell King (Oracle)]

On Mon, Oct 27, 2025 at 09:07:32AM +0000, Russell King (Oracle) wrote:
> The changes to stmmac have been tested on nVidia Jetson Xavier NX,
> which uses RGMII with dwmac4 and a RTL8211F PHY, connected to a Netgear
> GS108 switch. It seems to be the same that your board is using similar.
> 
> I will re-test today.

I just booted net-next on this platform.

# ethtool -S eth0 | grep lpi_mode_n
     irq_tx_path_in_lpi_mode_n: 24
     irq_tx_path_exit_lpi_mode_n: 23
     irq_rx_path_in_lpi_mode_n: 201
     irq_rx_path_exit_lpi_mode_n: 200
# ethtool --show-eee eth0
EEE Settings for eth0:
        EEE status: enabled - active
        Tx LPI: 1000000 (us)
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full

So it looks like everything is working as it should here.

stmmac was converted to phylink managed EEE in v6.14-rc1. I've built
v6.13 to check that my assertions w.r.t. EEE defaulting to being
enabled are correct, and:

# # ethtool -S eth0 | grep lpi
     irq_tx_path_in_lpi_mode_n: 15
     irq_tx_path_exit_lpi_mode_n: 14
     irq_rx_path_in_lpi_mode_n: 0
     irq_rx_path_exit_lpi_mode_n: 0
# ethtool --show-eee eth0
EEE Settings for eth0:
        EEE status: enabled - active
        Tx LPI: disabled
        Supported EEE link modes:  100baseT/Full
                                   1000baseT/Full
        Advertised EEE link modes:  100baseT/Full
                                    1000baseT/Full
        Link partner advertised EEE link modes:  100baseT/Full
                                                 1000baseT/Full

So, as I have asserted in response to Emanuele, the conversion of
stmmac to phylink-managed EEE hasn't changed whether EEE is enabled
by default. It was enabled by default before phylink-managed EEE, and
as I always try to do, I try to avoid introducing different behaviours
when converting drivers to a new implementation. That point holds up
here w.r.t. whether EEE is enabled by default. Hence, blaming these
problems on the phylink conversion enabling EEE by default is
incorrect - and I wish people would *stop* jumping to false conclusions
without evidence. As phylink maintainer, it is extremely disheartening
to keep having problems falsely levelled at phylink.

Note that the difference here is the receive path at the MAC doesn't
enter LPI mode. This is because PHY-mode EEE is enabled, which prevents
the LPI state on the receive side being forwarded to the MAC. I fixed
via commit bfc17c165835 ("net: phy: realtek: disable PHY-mode EEE") for
RTL8211F PHYs merged in v6.15-rc1.

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