Some PHYs implement autonomous EEE where the PHY manages EEE
independently, preventing the MAC from controlling LPI signaling.
This conflicts with MACs that implement their own LPI control.

This series adds a .disable_autonomous_eee callback to struct phy_driver
and calls it from phy_support_eee(). When a MAC indicates it supports
EEE, the PHY's autonomous EEE is automatically disabled. The setting is
persisted across suspend/resume by re-applying it in phy_init_hw() after
soft reset, following the same pattern suggested by Russell King for PHY
tunables [1].

Patch 1 adds the phylib infrastructure.
Patch 2 implements it for Broadcom BCM54xx (AutogrEEEn).
Patch 3 converts the Realtek RTL8211F, which previously unconditionally
  disabled PHY-mode EEE in config_init.

This came up while adding EEE support to the Cadence macb driver (used
on Raspberry Pi 5 with a BCM54210PE PHY). The PHY's AutogrEEEn mode
prevented the MAC from tracking LPI state. The Realtek RTL8211F has
the same pattern, unconditionally disabling PHY-mode EEE with the
comment "Disable PHY-mode EEE so LPI is passed to the MAC".

Other BCM54xx PHYs likely have the same AutogrEEEn register layout,
but I only have access to the BCM54210PE/BCM54213PE datasheets. It
would be appreciated if Florian or others could confirm which other
BCM54xx variants share this register so we can wire them up too.

Tested on Raspberry Pi CM4 (bcmgenet + BCM54210PE),
Raspberry Pi CM5 (Cadence GEM + BCM54210PE) and
Raspberry Pi 5 (Cadence GEM + BCM54213PE).

[1] https://lore.kernel.org/netdev/acuwvoydmJusuj9x@shell.armlinux.org.uk/

Previous versions:
  RFC: https://lore.kernel.org/netdev/20260403090656.733985-1-nb@tipi-net.de/
  Discussion: https://lore.kernel.org/netdev/d86c53213a6328b701b8aabbde5d1c83@tipi-net.de/

Changes since RFC:
  - Simplify kdoc and commit messages, remove references to specific
    callers (Andrew Lunn)

---
Nicolai Buchwitz (3):
      net: phy: add support for disabling PHY-autonomous EEE
      net: phy: broadcom: implement .disable_autonomous_eee for BCM54xx
      net: phy: realtek: convert RTL8211F to .disable_autonomous_eee

 drivers/net/phy/broadcom.c             |  7 +++++++
 drivers/net/phy/phy_device.c           | 22 ++++++++++++++++++++++
 drivers/net/phy/realtek/realtek_main.c |  7 ++++---
 include/linux/brcmphy.h                |  3 +++
 include/linux/phy.h                    | 14 ++++++++++++++
 5 files changed, 50 insertions(+), 3 deletions(-)
---
base-commit: 3741f8fa004bf598cd5032b0ff240984332d6f05
change-id: 20260406-devel-autonomous-eee-dffa292e9bb2

Best regards,
-- 
Nicolai Buchwitz <nb@tipi-net.de>

On Mon, 06 Apr 2026 09:13:06 +0200 Nicolai Buchwitz wrote:
> Some PHYs implement autonomous EEE where the PHY manages EEE
> independently, preventing the MAC from controlling LPI signaling.
> This conflicts with MACs that implement their own LPI control.

AFAIU the discussion that followed was about.. future work?
So this series is good as is. Applied, please LMK if I misread,
I'll drop it.

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?

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.

Thoughts?

	Andrew

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

> "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.

Yes, naming is hard.

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

This has come up before, in other context. PTP is one example, where
both the MAC and the PHY can implement it. Ideally, you want it to
happen at the PHY, it gives higher accuracy. But there are systems
where the PHY implementation is somewhat broken, and the MAC PTP gives
better results. So defaulting to PHY PTP is not always the best
option.

I would expect IEEE 802.3 EEE, with both the MAC and PHY cooperating
is better than just PHY level EEE, the system as a whole has a better
picture of what is going on, so using 802.3 EEE should be the
preference/default. But are we going to run into oddball systems where
autonomous EEE is actually better than using a somewhat broke MAC?

	Andrew

On 4/6/26 06:56, Andrew Lunn wrote:
>> "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.
> 
> Yes, naming is hard.
> 
>> I don't think there's a meaningful use case for letting users choose
>> between the two. Or is there?
> 
> This has come up before, in other context. PTP is one example, where
> both the MAC and the PHY can implement it. Ideally, you want it to
> happen at the PHY, it gives higher accuracy. But there are systems
> where the PHY implementation is somewhat broken, and the MAC PTP gives
> better results. So defaulting to PHY PTP is not always the best
> option.
> 
> I would expect IEEE 802.3 EEE, with both the MAC and PHY cooperating
> is better than just PHY level EEE, the system as a whole has a better
> picture of what is going on, so using 802.3 EEE should be the
> preference/default. But are we going to run into oddball systems where
> autonomous EEE is actually better than using a somewhat broke MAC?

That is almost a guarantee given, there will be a broken MAC, and there 
will be a need for enabling EEE at the PHY level because the power 
savings can be significant. Until that happens however, I would agree 
with using the global "--set-eee" without differentiating, and if we 
need to disable MAC-level EEE and switch to PHY-level EEE then we cross 
that bridge when necessary.
-- 
Florian

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.

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

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.

Maybe we need something similar to ethtool --set-hwtimestamp-cfg and
make the EEE provider selectable at runtime? Something like
ethtool --set-eee eth0 mode mac|phy. I have the feeling we will need
this sooner rather than later, given the overall quality of EEE
implementations out there...

Nicolai

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!

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