From: Nicolai Buchwitz <nb@tipi-net.de>
To: netdev@vger.kernel.org
Cc: Russell King <linux@armlinux.org.uk>, Andrew Lunn <andrew@lunn.ch>
Subject: RFC: phylink: disable PHY autonomous EEE when MAC manages LPI
Date: Tue, 31 Mar 2026 23:27:20 +0200 [thread overview]
Message-ID: <d86c53213a6328b701b8aabbde5d1c83@tipi-net.de> (raw)
Hi
Some PHYs (e.g. Broadcom BCM54xx "AutogrEEEn") manage EEE LPI
autonomously without forwarding LPI signaling to the MAC. This works
fine when the MAC doesn't support EEE, but conflicts with MACs that
implement their own LPI control via phylink's mac_enable_tx_lpi /
mac_disable_tx_lpi.
When the MAC has lpi_capabilities set, the PHY should use Native EEE
mode so the MAC can control LPI entry/exit and observe RX LPI
transitions.
I'm thinking of a flag on phy_device (similar to mac_managed_pm) that
phylink sets when the MAC has lpi_capabilities, and that PHY drivers
check in config_init to disable their autonomous EEE mode:
/* set by phylink when MAC manages LPI */
phydev->mac_managed_lpi = true;
/* in bcm54xx_config_init: */
if (phydev->mac_managed_lpi)
bcm_phy_modify_exp(phydev, MII_BUF_CNTL0,
AUTOGREEEN_EN, 0);
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. As a workaround, the
Raspberry Pi tree currently carries a downstream patch that
unconditionally disables AutogrEEEn for all BCM54xx PHYs, since both
genet and macb now support EEE properly. That's obviously not suitable
for upstream where other MACs paired with BCM54xx may not have LPI
support.
Does this seem like a reasonable approach, or is there a better way to
handle PHY autonomous EEE within phylink?
Thanks
Nicolai
next reply other threads:[~2026-03-31 21:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 21:27 Nicolai Buchwitz [this message]
2026-03-31 22:56 ` RFC: phylink: disable PHY autonomous EEE when MAC manages LPI Andrew Lunn
2026-04-01 7:43 ` Russell King (Oracle)
2026-04-01 12:12 ` Nicolai Buchwitz
2026-04-01 12:48 ` Russell King (Oracle)
2026-04-01 13:11 ` Andrew Lunn
2026-04-01 15:05 ` Russell King (Oracle)
2026-04-01 15:38 ` Andrew Lunn
2026-04-01 16:02 ` Russell King (Oracle)
2026-04-02 7:53 ` Nicolai Buchwitz
2026-04-02 12:32 ` Russell King (Oracle)
2026-04-02 13:32 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d86c53213a6328b701b8aabbde5d1c83@tipi-net.de \
--to=nb@tipi-net.de \
--cc=andrew@lunn.ch \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox