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

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

[Nicolai Buchwitz]

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>

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

[Nicolai Buchwitz]

Some PHYs (e.g. Broadcom BCM54xx, Realtek RTL8211F) implement
autonomous EEE where the PHY manages LPI signaling without forwarding
it to the MAC. This conflicts with MAC drivers that implement their own
LPI control.

Add a .disable_autonomous_eee callback to struct phy_driver and call it
from phy_support_eee(). When a MAC driver indicates it supports EEE via
phy_support_eee(), the PHY's autonomous EEE is automatically disabled so
the MAC can manage LPI entry/exit.

Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
 drivers/net/phy/phy_device.c | 22 ++++++++++++++++++++++
 include/linux/phy.h          | 14 ++++++++++++++
 2 files changed, 36 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0edff47478c20dd8537d4b94806be13b2409c711..cda4abf4e68cddb25b4ac69c35c8e095fac3e31c 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1375,6 +1375,14 @@ int phy_init_hw(struct phy_device *phydev)
 			return ret;
 	}
 
+	/* Re-apply autonomous EEE disable after soft reset */
+	if (phydev->autonomous_eee_disabled &&
+	    phydev->drv->disable_autonomous_eee) {
+		ret = phydev->drv->disable_autonomous_eee(phydev);
+		if (ret)
+			return ret;
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL(phy_init_hw);
@@ -2898,6 +2906,20 @@ void phy_support_eee(struct phy_device *phydev)
 	linkmode_copy(phydev->advertising_eee, phydev->supported_eee);
 	phydev->eee_cfg.tx_lpi_enabled = true;
 	phydev->eee_cfg.eee_enabled = true;
+
+	/* If the PHY supports autonomous EEE, disable it so the MAC can
+	 * manage LPI signaling instead. The flag is stored so it can be
+	 * re-applied after a PHY soft reset (e.g. suspend/resume).
+	 */
+	if (phydev->drv && phydev->drv->disable_autonomous_eee) {
+		int ret = phydev->drv->disable_autonomous_eee(phydev);
+
+		if (ret)
+			phydev_warn(phydev, "Failed to disable autonomous EEE: %pe\n",
+				    ERR_PTR(ret));
+		else
+			phydev->autonomous_eee_disabled = true;
+	}
 }
 EXPORT_SYMBOL(phy_support_eee);
 
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5de4b172cd0ba0048039d73d049b0ff24e8b2e44..199a7aaa341bfd9b13731e996a8de7e1aea586ff 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -612,6 +612,8 @@ struct phy_oatc14_sqi_capability {
  * @advertising_eee: Currently advertised EEE linkmodes
  * @enable_tx_lpi: When True, MAC should transmit LPI to PHY
  * @eee_active: phylib private state, indicating that EEE has been negotiated
+ * @autonomous_eee_disabled: Set when autonomous EEE has been disabled,
+ *	used to re-apply after PHY soft reset
  * @eee_cfg: User configuration of EEE
  * @lp_advertising: Current link partner advertised linkmodes
  * @host_interfaces: PHY interface modes supported by host
@@ -739,6 +741,7 @@ struct phy_device {
 	__ETHTOOL_DECLARE_LINK_MODE_MASK(eee_disabled_modes);
 	bool enable_tx_lpi;
 	bool eee_active;
+	bool autonomous_eee_disabled;
 	struct eee_config eee_cfg;
 
 	/* Host supported PHY interface types. Should be ignored if empty. */
@@ -1359,6 +1362,17 @@ struct phy_driver {
 	void (*get_stats)(struct phy_device *dev,
 			  struct ethtool_stats *stats, u64 *data);
 
+	/**
+	 * @disable_autonomous_eee: Disable PHY-autonomous EEE
+	 *
+	 * Some PHYs manage EEE autonomously, preventing the MAC from
+	 * controlling LPI signaling. This callback disables autonomous
+	 * EEE at the PHY.
+	 *
+	 * Return: 0 on success, negative errno on failure.
+	 */
+	int (*disable_autonomous_eee)(struct phy_device *dev);
+
 	/* Get and Set PHY tunables */
 	/** @get_tunable: Return the value of a tunable */
 	int (*get_tunable)(struct phy_device *dev,

-- 
2.51.0

[PATCH net-next 2/3] net: phy: broadcom: implement .disable_autonomous_eee for BCM54xx

[Nicolai Buchwitz]

Implement the .disable_autonomous_eee callback for the BCM54210E.

In AutogrEEEn mode the PHY manages EEE autonomously. Clearing the
AutogrEEEn enable bit in MII_BUF_CNTL_0 switches the PHY to Native
EEE mode.

Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
 drivers/net/phy/broadcom.c | 7 +++++++
 include/linux/brcmphy.h    | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index cb306f9e80cca6f810afcab967923dd1896638dd..bf0c6a04481ee23110e249118bbe086ffe8e7a8f 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -1452,6 +1452,12 @@ static int bcm54811_read_status(struct phy_device *phydev)
 	return genphy_read_status(phydev);
 }
 
+static int bcm54xx_disable_autonomous_eee(struct phy_device *phydev)
+{
+	return bcm_phy_modify_exp(phydev, BCM54XX_TOP_MISC_MII_BUF_CNTL0,
+				  BCM54XX_MII_BUF_CNTL0_AUTOGREEEN_EN, 0);
+}
+
 static struct phy_driver broadcom_drivers[] = {
 {
 	PHY_ID_MATCH_MODEL(PHY_ID_BCM5411),
@@ -1495,6 +1501,7 @@ static struct phy_driver broadcom_drivers[] = {
 	.get_wol	= bcm54xx_phy_get_wol,
 	.set_wol	= bcm54xx_phy_set_wol,
 	.led_brightness_set	= bcm_phy_led_brightness_set,
+	.disable_autonomous_eee	= bcm54xx_disable_autonomous_eee,
 }, {
 	PHY_ID_MATCH_MODEL(PHY_ID_BCM5461),
 	.name		= "Broadcom BCM5461",
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 115a964f3006965e9bfd247eb969b9ca586ae675..174687c4c80a8b12eb841cdb4e8865813bb34adc 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -266,6 +266,9 @@
 #define BCM54XX_TOP_MISC_IDDQ_SD		(1 << 2)
 #define BCM54XX_TOP_MISC_IDDQ_SR		(1 << 3)
 
+#define BCM54XX_TOP_MISC_MII_BUF_CNTL0		(MII_BCM54XX_EXP_SEL_TOP + 0x00)
+#define  BCM54XX_MII_BUF_CNTL0_AUTOGREEEN_EN	BIT(0)
+
 #define BCM54XX_TOP_MISC_LED_CTL		(MII_BCM54XX_EXP_SEL_TOP + 0x0C)
 #define  BCM54XX_LED4_SEL_INTR			BIT(1)
 

-- 
2.51.0

[PATCH net-next 3/3] net: phy: realtek: convert RTL8211F to .disable_autonomous_eee

[Nicolai Buchwitz]

The RTL8211F previously unconditionally disabled PHY-mode EEE in
config_init. Convert this to use the new .disable_autonomous_eee
callback so it is only disabled when the MAC indicates EEE support
via phy_support_eee().

This preserves PHY-autonomous EEE for MACs that do not support EEE,
while still disabling it when the MAC manages LPI.

Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
 drivers/net/phy/realtek/realtek_main.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 023e47ad605bde57287d3da8b80c47d97d898b96..b7c96b020baf6f2ae8c5fe71d1fc3cbf7c6e2bc7 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -700,9 +700,8 @@ static int rtl8211f_config_aldps(struct phy_device *phydev)
 	return phy_modify(phydev, RTL8211F_PHYCR1, mask, mask);
 }
 
-static int rtl8211f_config_phy_eee(struct phy_device *phydev)
+static int rtl8211f_disable_autonomous_eee(struct phy_device *phydev)
 {
-	/* Disable PHY-mode EEE so LPI is passed to the MAC */
 	return phy_modify(phydev, RTL8211F_PHYCR2,
 			  RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
 }
@@ -730,7 +729,7 @@ static int rtl8211f_config_init(struct phy_device *phydev)
 		return ret;
 	}
 
-	return rtl8211f_config_phy_eee(phydev);
+	return 0;
 }
 
 static int rtl821x_suspend(struct phy_device *phydev)
@@ -2324,6 +2323,7 @@ static struct phy_driver realtek_drvs[] = {
 		.led_hw_is_supported = rtl8211x_led_hw_is_supported,
 		.led_hw_control_get = rtl8211f_led_hw_control_get,
 		.led_hw_control_set = rtl8211f_led_hw_control_set,
+		.disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
 	}, {
 		PHY_ID_MATCH_EXACT(RTL_8211FVD_PHYID),
 		.name		= "RTL8211F-VD Gigabit Ethernet",
@@ -2340,6 +2340,7 @@ static struct phy_driver realtek_drvs[] = {
 		.led_hw_is_supported = rtl8211x_led_hw_is_supported,
 		.led_hw_control_get = rtl8211f_led_hw_control_get,
 		.led_hw_control_set = rtl8211f_led_hw_control_set,
+		.disable_autonomous_eee = rtl8211f_disable_autonomous_eee,
 	}, {
 		.name		= "Generic FE-GE Realtek PHY",
 		.match_phy_device = rtlgen_match_phy_device,

-- 
2.51.0

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

[Andrew Lunn]

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

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

[Nicolai Buchwitz]

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

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

[Andrew Lunn]

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

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

[Florian Fainelli]

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

Re: [PATCH net-next 2/3] net: phy: broadcom: implement .disable_autonomous_eee for BCM54xx

[Florian Fainelli]

On 4/6/26 00:13, Nicolai Buchwitz wrote:
> Implement the .disable_autonomous_eee callback for the BCM54210E.
> 
> In AutogrEEEn mode the PHY manages EEE autonomously. Clearing the
> AutogrEEEn enable bit in MII_BUF_CNTL_0 switches the PHY to Native
> EEE mode.
> 
> Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>

Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian

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

[Russell King (Oracle)]

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!

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

[Nicolai Buchwitz]

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

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

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

[Russell King (Oracle)]

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!