On Mon, Apr 06, 2026 at 08:29:38PM +0200, Nicolai Buchwitz wrote:

On 6.4.2026 19:10, Russell King (Oracle) wrote:

quoted

On Mon, Apr 06, 2026 at 09:43:55AM -0700, Florian Fainelli wrote:

quoted

That is almost a guarantee given, there will be a broken MAC

Well, it already exists. modern i.MX platforms use stmmac, and some
bright spark wired lpi_intr_o together with the main stmmac interrupt
which causes interrupt storms when the receive path exits LPI. This
makes stmmac LPI unusable on this platform.

So, if i.MX is paired with a PHY that can do its own EEE, then we
have this exact scenaro.

For DT-based platforms (like the broken i.MX), this could be addressed
similar to what we already have with eee-broken-* properties. For
platforms without DT it's getting more complicated and I can't see a
way without ethtool.

No. It's not that EEE itself is broken, it's that the integration of
the stmmac IP into the SoC is broken. We already have a solution to
disable LPI at stmmac (the STMMAC_FLAG_EEE_DISABLE flag).

That tells stmmac that the MAC doesn't support LPI signalling for an
speed and any interface mode, and will result in phy_disable_eee()
being called, which clears the EEE advertisement, disables LPI, EEE
enables, and fills phydev->eee_disabled_modes.

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