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

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

[Nicolai Buchwitz]

Some PHYs implement autonomous EEE where the PHY manages LPI signaling
without forwarding it to the MAC. This conflicts with MACs that
implement their own LPI control via phylink's mac_enable_tx_lpi /
mac_disable_tx_lpi callbacks.

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 so the MAC can
manage LPI entry/exit. 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 discussion:
  https://lore.kernel.org/netdev/d86c53213a6328b701b8aabbde5d1c83@tipi-net.de/

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                    | 18 ++++++++++++++++++
 5 files changed, 54 insertions(+), 3 deletions(-)

-- 
2.51.0

[RFC 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          | 18 ++++++++++++++++++
 2 files changed, 40 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0edff47478c2..cda4abf4e68c 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 5de4b172cd0b..55d9cc6c3605 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 via
+ *	phy_support_eee(), 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,21 @@ 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 LPI autonomously without forwarding LPI
+	 * signaling to the MAC. This callback disables autonomous EEE so
+	 * that the MAC can control LPI entry/exit.
+	 *
+	 * Called by phy_support_eee() when the MAC indicates it supports
+	 * EEE. PHY drivers that implement autonomous EEE should provide
+	 * this callback.
+	 *
+	 * 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

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

[Andrew Lunn]

> + * @autonomous_eee_disabled: Set when autonomous EEE has been disabled via
> + *	phy_support_eee(), used to re-apply after PHY soft reset

Thinking ahead to when autonomous EEE is supported, there will be
other reasons to disable it than just phy_support_eee(). So i would
not say this here.

>   * @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,21 @@ 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 LPI autonomously without forwarding LPI
> +	 * signaling to the MAC.

My understanding is that LPI is always from the MAC to the PHY?


> +	 * Called by phy_support_eee() when the MAC indicates it supports
> +	 * EEE. PHY drivers that implement autonomous EEE should provide
> +	 * this callback.

Again, there will be other reasons to call this, than just
phy_support_eee().

    Andrew

---
pw-bot: cr
	

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

[Nicolai Buchwitz]

On 3.4.2026 17:27, Andrew Lunn wrote:
>> + * @autonomous_eee_disabled: Set when autonomous EEE has been 
>> disabled via
>> + *	phy_support_eee(), used to re-apply after PHY soft reset
> 
> Thinking ahead to when autonomous EEE is supported, there will be
> other reasons to disable it than just phy_support_eee(). So i would
> not say this here.

Makes sense. I will amend all comments accordingly.
> 
>>   * @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,21 @@ 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 LPI autonomously without forwarding LPI
>> +	 * signaling to the MAC.
> 
> My understanding is that LPI is always from the MAC to the PHY?

Probably not the right wording, agreed. I was thinking of the RX LPI
counter on macb, which wasn't incrementing until I noticed that the PHY
had AutogrEEEn enabled. After disabling it, the RX LPI signaling
worked.
> 
> 
>> +	 * Called by phy_support_eee() when the MAC indicates it supports
>> +	 * EEE. PHY drivers that implement autonomous EEE should provide
>> +	 * this callback.
> 
> Again, there will be other reasons to call this, than just
> phy_support_eee().

Will do.

> 
>     Andrew
> 
> ---
> pw-bot: cr

Thanks for the prompt review

Nicolai

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

[Russell King (Oracle)]

On Fri, Apr 03, 2026 at 05:27:33PM +0200, Andrew Lunn wrote:
> > +	/**
> > +	 * @disable_autonomous_eee: Disable PHY-autonomous EEE
> > +	 *
> > +	 * Some PHYs manage EEE LPI autonomously without forwarding LPI
> > +	 * signaling to the MAC.
> 
> My understanding is that LPI is always from the MAC to the PHY?

It's bi-directional. The MAC sends LPI, but it also receives LPI from
the PHY as well.

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

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

[Nicolai Buchwitz]

Disable AutogrEEEn mode on BCM54210E when the MAC indicates EEE support
via phy_support_eee(). In AutogrEEEn mode the PHY manages LPI
autonomously without forwarding LPI signaling to the MAC over the RGMII
interface, which prevents the MAC from controlling TX LPI entry/exit.

Clearing the AutogrEEEn enable bit in MII_BUF_CNTL_0 switches the PHY
to Native EEE mode where the MAC controls TX LPI and the PHY forwards
received LPI on the RGMII interface.

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 cb306f9e80cc..bf0c6a04481e 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 115a964f3006..174687c4c80a 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

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

[Andrew Lunn]

On Fri, Apr 03, 2026 at 11:06:52AM +0200, Nicolai Buchwitz wrote:
> Disable AutogrEEEn mode on BCM54210E when the MAC indicates EEE support
> via phy_support_eee(). In AutogrEEEn mode the PHY manages LPI

At the driver level, it should not matter why this is called, what is
happening above. It should just do what it is told.

    Andrew

---
pw-bot: cr

[RFC 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 023e47ad605b..b7c96b020baf 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: [RFC PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE

[Andrew Lunn]

On Fri, Apr 03, 2026 at 11:06:50AM +0200, Nicolai Buchwitz wrote:
> Some PHYs implement autonomous EEE where the PHY manages LPI signaling
> without forwarding it to the MAC. This conflicts with MACs that
> implement their own LPI control via phylink's mac_enable_tx_lpi /
> mac_disable_tx_lpi callbacks.
> 
> 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 so the MAC can
> manage LPI entry/exit. 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].

I think the general direction of these patches are good, just some
nitpicks to sort out.

Thanks
	Andrew