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

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

On Mon, Oct 27, 2025 at 10:12:12AM +0100, Oleksij Rempel wrote:
> Please note, RTL8211E PHY do use undocumented SmartEEE mode by default.

Same as RTL8211F I believe (as used on the Jetson Xavier NX platform I
have.) I submitted commit bfc17c165835 ("net: phy: realtek: disable
PHY-mode EEE") to get EEE working on this platform.

> It ignores RGMII LPI opcodes and doing own thing. It can be confirmed by
> monitoring RGMII TX and MDI lines with oscilloscope and changing
> tx-timer configurations. I also confirmed this information from other
> source. To disable SmartEEE and use plain MAC based mode, NDA documentation
> is needed.

What I saw there was similar to what you describe (although I have no
way to monitor these signals.) No interrupt storms, but while the
stmmac TX path would enter LPI mode (whether that provoked anything
in the PHY, I do not know), the RX path never entered LPI mode because
the PHY never forwarded that status.

So, I don't think having SmartEEE enabled on the RTL8211E would cause
this interrupt storm that Laurent is reporting.

In Emanuele's case, things are different. The TI PHY reports that EEE
is supported, implements the autoneg registers for EEE, but *doesn't*
implement the necessary hardware for detecting/entering/exiting LPI
mode. So, if EEE is negotiated, the remote end thinks it can enter
LPI mode... which likely causes the link to drop as the TI PHY can't
cope with that, and I suspect that's the cause of Emanuele's problem.

I'm wondering why "arm64: dts: imx8mp: add cpuidle state "cpu-pd-wait""
impacts this - could it be that entering the idle state does more than
just affecting the CPU domain, but interferes with the EQOS domain in
some way. Given that the entry/exit to this state is all buried in
PSCI stuff, without digging through the ATF implementation for this
platform and then cross-referencing the iMX8M documentation, I don't
know what effect this has on the system. Is it possible that PSCI is
messing with the EQOS?

What about the clock tree? Is it possible that the stmmac and/or RGMII
clocks could be lost when cpu-pd-wait state is entered on all CPUs?

Has anyone checked whether there's anything in the errata
documentation?

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