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

[Andrew Lunn]

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.

i.MX is not actually an issue. The MAC EEE is so broken we don't
consider using it. Since it never calls phy_support_eee() PHY EEE will
be used.

It gets more interesting when we actually have PHY EEE support. And a
board using it. And then somebody adds support for MAC EEE which is
partially broken, but better than nothing. It calls phy_support_eee(),
so disabling PHY EEE, which can cause a board using PHY EEE to
regress, because the poor MAC EEE is worse than the PHY EEE which just
got disabled.

With PTP we talked about adding some sort of quality value, so we can
rank the implementations and pick the best. But that never got
implemented.

It is these sorts of corner case regressions which are hard to deal
with.

	Andrew