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

[Nicolai Buchwitz <nb@tipi-net.de>]

On 6.4.2026 15:17, Andrew Lunn wrote:
> On Mon, Apr 06, 2026 at 09:13:06AM +0200, Nicolai Buchwitz wrote:
>> Some PHYs implement autonomous EEE where the PHY manages EEE
>> independently
> 
> I suppose we should discuss naming. As far as i know, IEEE 802.3 does
> not include this feature, so it does not provide a guide to how we
> should name it.
> 
> In the past we have used SmartEEE, but that is Atheros's vendor
> name. Broadcom seem to call it AutoGrEEEn.
> 
> Autonomous EEE seems like a reasonable name, and appears to be vendor
> agnostic. Are we happy with this?

"Autonomous EEE" works for me (obviously). It kinda describes what
happens (the PHY acts autonomously) without being tied to a specific
vendor's marketing name.

That said, I feel Russell's argument that it doesn't type well. But
even after some walks in the woods I wasn't able to come up with a
better name yet.

> 
> What i guess is unclear is what part of the network stack is acting
> autonomously. In the context of a PHY driver op,
> .disable_autonomous_eee is clear. But when we go further to actually
> making use of it, do we need to report to user space if we are using
> IEEE 802.3 EEE or "autonomous EEE". But i guess it is no worse than
> SmartEEE or AutoGrEEEn which also make no indication where EEE is
> happening.

I think for now it's fine to not expose this. From the user's 
perspective,
EEE is either on or off. Whether the PHY or MAC manages LPI is an
implementation detail. ethtool --set-eee should just do the right thing:

- MAC supports LPI: use MAC-managed EEE
- MAC doesn't, but PHY has autonomous EEE: use that instead
- Neither: EOPNOTSUPP

I don't think there's a meaningful use case for letting users choose
between the two. Or is there?

> 
> Thoughts?
> 
> 	Andrew

Nicolai