Re: [PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE

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

On Mon, Apr 06, 2026 at 08:29:38PM +0200, Nicolai Buchwitz wrote:
> On 6.4.2026 19:10, Russell King (Oracle) wrote:
> > On Mon, Apr 06, 2026 at 09:43:55AM -0700, Florian Fainelli wrote:
> > > 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!