[PATCH net 0/2] net: restore EEE on MediaTek switches and SoC MACs

[PATCH net 0/2] net: restore EEE on MediaTek switches and SoC MACs

[Aleksei Sviridkin]

Both drivers fill in phylink_config.lpi_capabilities and
lpi_timer_default but never lpi_interfaces. phylink treats a MAC as
supporting managed EEE only when the tx_lpi methods are implemented and
BOTH bitmaps are non-empty, which phylink_create() decides once and for
all, so EEE has been off on every mt753x port and on every mtk_eth_soc
MAC that uses mtk_phylink_ops since the two conversions named in the
Fixes: tags. Because the tx_lpi methods ARE implemented, phylink takes
the other branch and calls phy_disable_eee(), which fills
eee_disabled_modes - so userspace cannot enable EEE either.

On an MT7981B board with an MT7531 switch, before these patches:

  == lan1
  Cannot get EEE settings: Not supported
  == lan2
  Cannot get EEE settings: Not supported
  == lan3
  Cannot get EEE settings: Not supported
  == lan4
  Cannot get EEE settings: Not supported
  == wan
  Cannot get EEE settings: Not supported

lan1-3 are the MT7531 internal PHYs, lan4 is an EN8811H on switch port
5 whose MAC side runs 2500BASE-X rate matched to a 1 Gbps media link,
and wan is the mtk_eth_soc MAC with its directly attached 1 Gbps PHY -
so both drivers are covered.

On MT7531 this undoes half of a deliberate arrangement.
Commit 06dfcd4098cf ("net: dsa: mt7530: fix enabling EEE on MT7531
switch on all boards") turned EEE on at the switch MACs while zeroing
the switch PHYs' EEE advertisement, and ended "With this change, EEE
can now be enabled using ethtool". Only the "off out of the box" half
survives.

Each patch fills lpi_interfaces from supported_interfaces, minus the
interfaces the MAC cannot signal LPI on, and corrects lpi_capabilities,
which takes effect for the first time as a result: neither MAC has EEE
force bits above 1 Gbps. Neither driver sets eee_enabled_default, so
LPI stays off until userspace asks for it with ethtool --set-eee. The
EEE advertisement is a different matter: phylink stops force-clearing
it, so a PHY that advertises EEE out of reset advertises it again and
the link may negotiate EEE, without this MAC asserting LPI. There are
two exceptions: MT7531's five internal PHYs, whose advertisement
mt7531_setup() zeroes before they are probed, and EN7528, where the
driver deliberately leaves both LPI bitmaps empty so phylink keeps
taking the phy_disable_eee() branch.

The two patches are independent and touch different subsystems; they
are sent together because they are the same bug.

Splitting each patch further - lpi_interfaces in one, the
lpi_capabilities correction in another - was considered and rejected: a
value that never reached phy->advertising_eee is not a reviewable
behavioural unit on its own, and the split would leave an intermediate
commit claiming 2.5 Gbps LPI that the registers do not implement.

Targeted at net as a regression fix with an active userspace lockout;
can be retargeted at net-next if maintainers prefer.

Based on net-next at 91ec20351349. Both driver files are byte
identical in net/main and the series applies there unchanged.

After the series, all five ports report:

  EEE status: disabled
  Tx LPI: disabled
  Supported EEE link modes:  100baseT/Full
                             1000baseT/Full
  Advertised EEE link modes:  Not reported

No 2.5G mode is offered, which is the corrected lpi_capabilities, and
nothing is advertised until userspace asks. On this board no PHY came
out of reset advertising EEE, so the case where the advertisement
returns once phylink stops clearing it is not exercised here.

Enabling it on lan1, whose partner advertises EEE at both speeds:

  # ethtool --set-eee lan1 eee on
  EEE status: enabled - active
  Advertised EEE link modes:  100baseT/Full 1000baseT/Full
  Link partner advertised EEE link modes:  100baseT/Full 1000baseT/Full

  # ethtool --set-eee lan1 eee on tx-lpi on
  EEE status: enabled - active
  Tx LPI: 30 (us)

With LPI armed, 30 parallel ICMPv6 streams of 1400-byte payload, 300
packets each one second apart - so every gap crosses the LPI threshold
and the link enters and leaves LPI thousands of times over 300 s - lost
nothing: 300/300 on every stream, tx and rx error counters unchanged,
carrier_changes unchanged, and no mac_enable_tx_lpi errors in dmesg.

On wan the link partner advertises no EEE, so enabling it settles at
"enabled - inactive", which is the correct outcome, and the link
survived the autonegotiation restart. Its Tx LPI reads 1000 (us)
against lan1's 30; see the note below the scissors of patch 1.

lan4 keeps EEE disabled and never arms LPI, which is what dropping
2500BASE-X from lpi_interfaces is for. Forwarding through it was
lossless with no carrier change.

Aleksei Sviridkin (2):
  net: dsa: mt7530: populate lpi_interfaces to fix EEE support
  net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support

 drivers/net/dsa/mt7530.c                    | 24 ++++++++++++++++-----
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 22 ++++++++++++++++---
 2 files changed, 38 insertions(+), 8 deletions(-)

-- 
2.55.0

[PATCH net 1/2] net: dsa: mt7530: populate lpi_interfaces to fix EEE support

[Aleksei Sviridkin]

mt753x_phylink_get_caps() fills in config->lpi_capabilities and
config->lpi_timer_default, but never populates config->lpi_interfaces.
phylink only treats a MAC as supporting phylink managed EEE when the
tx_lpi methods are implemented and both the LPI capabilities and the
LPI interfaces are non-empty, so EEE is unavailable on every port:

  # ethtool --show-eee lan1
  Cannot get EEE settings: Not supported

even though the driver implements mac_enable_tx_lpi() and
mac_disable_tx_lpi() and reads the LPI threshold back out of PMEEECR.
Since the tx_lpi methods are implemented, phylink takes the other
branch and calls phy_disable_eee(), which fills eee_disabled_modes, so
userspace cannot enable EEE either.

Only the first half of what commit 06dfcd4098cf ("net: dsa: mt7530: fix
enabling EEE on MT7531 switch on all boards") arranged therefore
survives. It left EEE off out of the box on purpose, by having
mt7531_setup() clear the switch PHYs' EEE advertisement, and ended
"With this change, EEE can now be enabled using ethtool". It cannot be,
any more.

Copy the supported interfaces into lpi_interfaces. This requires moving
the mac_port_get_caps() call ahead of the EEE block, since that is what
populates supported_interfaces - copying it beforehand would copy an
empty bitmap.

LPI stays off by default. The driver does not set eee_enabled_default,
so phylink leaves tx_lpi_enabled false, and phy_check_link_status()
computes enable_tx_lpi as tx_lpi_enabled && eee_active - nothing
asserts LPI until userspace enables it with ethtool --set-eee. The EEE
advertisement is the part that does change: phylink no longer takes the
phy_disable_eee() branch, so a PHY that advertises EEE out of reset
advertises it again and the link may negotiate EEE. MT7531's five
internal PHYs are the exception, as mt7531_setup() zeroes
MDIO_AN_EEE_ADV before the switch MDIO bus is registered, so
phy_probe() reads an empty advertisement and records eee_cfg.eee_enabled
as false. Nothing does that for an external PHY on port 5 or 6, or on
the other mt753x variants, EN7528 aside - see below.

This also makes lpi_capabilities take effect for the first time, so
correct its value in the same change. PMCR only has force bits for
100 Mbps (PMCR_FORCE_EEE100) and 1 Gbps (PMCR_FORCE_EEE1G), and PMSR
only reports EEE state for those two speeds, so the MAC cannot signal
LPI at 2.5 Gbps: drop MAC_2500FD. Absence from the header is weak
evidence on its own, so for what it is worth, the Airoha AN8855 DSA
driver - posted but not merged [1] - describes a PMCR of the same shape
that does carry AN8855_PMCR_FORCE_EEE2P5G and AN8855_PMCR_FORCE_EEE5G
next to the 1 Gbps and 100 Mbps bits. Correcting the value here rather
than in a separate patch changes nothing observable: while
lpi_interfaces was empty, lpi_capabilities never reached
phy->advertising_eee, so no state ever claimed 2.5 Gbps LPI.

2500BASE-X has to come out of lpi_interfaces as well, because
lpi_capabilities cannot express it: it masks the PHY's EEE
advertisement, a media side property, and never gates LPI activation on
the MAC side speed. phylink raises the MAC speed to the interface
maximum when the PHY rate matches (RATE_MATCH_PAUSE in
phylink_link_up()), so a 1 Gbps media link behind a rate matching 2.5G
PHY would otherwise arm LPI while the MAC runs at 2.5 Gbps. What that
costs is limited to setups that keep the MAC on 2500BASE-X, where there
are no LPI bits to use anyway; a PHY that switches the interface down
to SGMII or 1000BASE-X keeps LPI, as those stay in the mask.

For the same reason, skip ports that support neither 100 Mbps nor
1 Gbps: on MT7988, EN7581 and AN7583, port 6 is 10 Gbps only, and it
shares PHY_INTERFACE_MODE_INTERNAL with the 1 Gbps user ports, so the
interface mask alone cannot tell them apart.

EEE remains unavailable on EN7528, whose GPHYs do not negotiate it
reliably. Both LPI bitmaps stay empty there, so phylink keeps taking
the phy_disable_eee() branch and its advertisement stays off.

[1] https://lore.kernel.org/r/20250315154407.26304-14-ansuelsmth@gmail.com

Fixes: 9cf21773f535 ("net: dsa: mt7530: convert to phylink managed EEE")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
---

Two pre-existing things this patch makes live, neither addressed here:

- The unit of LPI_THRESH is still unspecified, as the comment above
  lpi_timer_default says. With EEE reachable again, ethtool reports
  that raw value as microseconds and writes userspace values back
  unconverted, while mtk_eth_soc treats a structurally identical field
  as milliseconds (DIV_ROUND_UP(timer, 1000)). Reading the default back
  reproduces the same raw value whatever the unit is, but a timer set
  from userspace in microseconds would be off by 1000 if the field is
  in milliseconds. On an MT7531 board ethtool now reports 30 for a
  switch port, which is the raw LPI_THRESH field; whether the hardware
  means 30 microseconds is exactly the open question. Does anyone have
  the datasheet answer?

- mt753x_phylink_mac_enable_tx_lpi() sets the PMCR force-EEE bits
  without checking the resolved speed or interface, relying entirely on
  phylink never calling it above 1 Gbps. A check there would make the
  driver robust independently of lpi_interfaces being right;
  deliberately not bundled into a fix.
 drivers/net/dsa/mt7530.c | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 2b7be091c056..17265eb79008 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -3172,23 +3172,37 @@ static void mt753x_phylink_get_caps(struct dsa_switch *ds, int port,
 
 	config->mac_capabilities = MAC_ASYM_PAUSE | MAC_SYM_PAUSE;
 
+	priv->info->mac_port_get_caps(ds, port, config);
+
 	/* The EN7528 GPHYs report EEE capability, but negotiating EEE with
 	 * common link partners (e.g. Realtek GbE NICs) results in an unstable
 	 * link with dropped frames. Leave the LPI capabilities empty so that
 	 * phylink disables EEE on these PHYs and refuses to enable it from
-	 * userspace.
+	 * userspace. Ports that run at neither 100 Mbps nor 1 Gbps are left
+	 * empty too, as PMCR has no force bit that would apply to them.
 	 */
-	if (priv->id != ID_EN7528) {
+	if (priv->id != ID_EN7528 &&
+	    config->mac_capabilities & (MAC_100FD | MAC_1000FD)) {
 		u32 eeecr = mt7530_read(priv, MT753X_PMEEECR_P(port));
 
-		config->lpi_capabilities = MAC_100FD | MAC_1000FD | MAC_2500FD;
+		/* PMCR only has force bits for 100 Mbps and 1 Gbps. That also
+		 * rules out 2500BASE-X, which lpi_capabilities cannot express:
+		 * it masks the PHY's EEE advertisement, a media side property,
+		 * and never gates LPI activation on the MAC side speed. The
+		 * MAC side of 2500BASE-X is never below 2.5 Gbps, not even
+		 * when a rate matching PHY drops the media to 1 Gbps.
+		 */
+		config->lpi_capabilities = MAC_100FD | MAC_1000FD;
+		phy_interface_copy(config->lpi_interfaces,
+				   config->supported_interfaces);
+		__clear_bit(PHY_INTERFACE_MODE_2500BASEX,
+			    config->lpi_interfaces);
+
 		/* tx_lpi_timer should be in microseconds. The time units for
 		 * LPI threshold are unspecified.
 		 */
 		config->lpi_timer_default = FIELD_GET(LPI_THRESH_MASK, eeecr);
 	}
-
-	priv->info->mac_port_get_caps(ds, port, config);
 }
 
 static int mt753x_pcs_validate(struct phylink_pcs *pcs,
-- 
2.55.0

[PATCH net 2/2] net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support

[Aleksei Sviridkin]

mtk_add_mac() fills in phylink_config.lpi_capabilities and
phylink_config.lpi_timer_default, but never populates
phylink_config.lpi_interfaces. phylink only treats a MAC as supporting
phylink managed EEE when the tx_lpi methods are implemented and both
the LPI capabilities and the LPI interfaces are non-empty, so EEE is
unavailable on every MAC that uses mtk_phylink_ops:

  # ethtool --show-eee wan
  Cannot get EEE settings: Not supported

even though those ops implement mac_enable_tx_lpi() and
mac_disable_tx_lpi(). Since the methods are implemented, phylink takes
the other branch and calls phy_disable_eee(), which fills
eee_disabled_modes, so userspace cannot enable EEE either. MT7628 is
unaffected, as rt5350_phylink_ops has no tx_lpi methods at all.

Copy the supported interfaces into lpi_interfaces once they are
complete, that is after the SoC specific fixups have added and removed
modes. In particular the netsys v3 switch path clears the bitmap
before setting PHY_INTERFACE_MODE_INTERNAL, so copying it any earlier
would leave stale modes behind.

The MAC does not start using LPI on its own: the driver does not set
eee_enabled_default, so phylink leaves tx_lpi_enabled false, and
phy_check_link_status() computes enable_tx_lpi as tx_lpi_enabled &&
eee_active. One thing does change, and it is worth being explicit
about: phylink no longer takes the phy_disable_eee() branch, so a PHY
that advertises EEE out of reset advertises it again instead of being
forced quiet, and the link may negotiate EEE where it previously could
not. Nothing on this side asserts LPI until userspace enables it with
ethtool --set-eee.

This also makes lpi_capabilities take effect for the first time, so
correct its value in the same change. MAC_MCR only has EEE force bits
for 100 Mbps (MAC_MCR_EEE100M) and 1 Gbps (MAC_MCR_EEE1G), and
MAC_EEECR only carries wakeup times for those two speeds
(MAC_EEE_WAKEUP_TIME_100, MAC_EEE_WAKEUP_TIME_1000), so the MAC cannot
signal LPI at 2.5 Gbps: drop MAC_2500FD. Correcting the value here
rather than in a separate patch changes nothing observable: while
lpi_interfaces was empty, lpi_capabilities never reached
phy->advertising_eee, so no state ever claimed 2.5 Gbps LPI.

Two sets of interfaces have to come out of lpi_interfaces as well.
lpi_capabilities cannot express either: it masks the PHY's EEE
advertisement, a media side property, and never gates LPI activation on
the MAC side speed, while phylink raises the MAC speed to the interface
maximum when the PHY rate matches (RATE_MATCH_PAUSE in
phylink_link_up()), so 2500BASE-X would arm LPI on a 2.5 Gbps MAC even
for a 1 Gbps media link. Separately, mtk_mac_enable_tx_lpi() refuses
the xGMII modes outright, which on netsys v3 includes
PHY_INTERFACE_MODE_INTERNAL, the mode MT7988's built-in 2.5G PHY runs
in; offering those to phylink would log an error on link up once EEE is
enabled. What that costs is limited to setups that keep the MAC on
2500BASE-X or on an xGMII mode, neither of which the MAC has LPI bits
for; a PHY that switches the interface down to SGMII or 1000BASE-X
keeps LPI, as those stay in the mask.

On the netsys v3 switch MAC, that empties lpi_interfaces outright,
since PHY_INTERFACE_MODE_INTERNAL is the only interface it supports.
Nothing changes there: it is a fixed link port with no PHY, so phylink
had no EEE to manage on it before this patch either.

Fixes: 952d7325362f ("net: ethernet: mediatek: add EEE support")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
---

Pre-existing, made live by this patch and not addressed here:
mtk_mac_enable_tx_lpi() programs MT7531's reset wakeup times (17 for
1 Gbps, 36 for 100 Mbps) whenever it runs, as its own comment says, so
they now apply to every SoC driven by mtk_phylink_ops once a user
enables EEE on an eligible interface. Those values do not appear to
have been confirmed for MT7981, MT7986 or MT7988.
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 22 ++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index be3bd025c41a..5412c89685f2 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -4828,7 +4828,7 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	phy_interface_t phy_mode;
 	struct phylink *phylink;
 	struct mtk_mac *mac;
-	int id, err;
+	int id, err, i;
 	int txqs = 1;
 	u32 val;
 
@@ -4907,8 +4907,11 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 	mac->phylink_config.type = PHYLINK_NETDEV;
 	mac->phylink_config.mac_capabilities = MAC_ASYM_PAUSE | MAC_SYM_PAUSE |
 		MAC_10 | MAC_100 | MAC_1000 | MAC_2500FD;
-	mac->phylink_config.lpi_capabilities = MAC_100FD | MAC_1000FD |
-		MAC_2500FD;
+	/* MAC_MCR only has EEE force bits for 100 Mbps and 1 Gbps, and
+	 * MAC_EEECR only has wakeup times for those two speeds, so the MAC
+	 * cannot signal LPI at 2.5 Gbps.
+	 */
+	mac->phylink_config.lpi_capabilities = MAC_100FD | MAC_1000FD;
 	mac->phylink_config.lpi_timer_default = 1000;
 
 	/* MT7623 gmac0 is now missing its speed-specific PLL configuration
@@ -4966,6 +4969,19 @@ static int mtk_add_mac(struct mtk_eth *eth, struct device_node *np)
 		__set_bit(PHY_INTERFACE_MODE_INTERNAL,
 			  mac->phylink_config.supported_interfaces);
 
+	phy_interface_copy(mac->phylink_config.lpi_interfaces,
+			   mac->phylink_config.supported_interfaces);
+
+	/* The MAC side of 2500BASE-X is never below 2.5 Gbps, not even when
+	 * a rate matching PHY drops the media to 1 Gbps, and
+	 * mtk_mac_enable_tx_lpi() refuses the xGMII modes outright.
+	 */
+	__clear_bit(PHY_INTERFACE_MODE_2500BASEX,
+		    mac->phylink_config.lpi_interfaces);
+	for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++)
+		if (mtk_interface_mode_is_xgmii(eth, i))
+			__clear_bit(i, mac->phylink_config.lpi_interfaces);
+
 	phylink = phylink_create(&mac->phylink_config,
 				 of_fwnode_handle(mac->of_node),
 				 phy_mode, mac_ops);
-- 
2.55.0

Re: [PATCH net 1/2] net: dsa: mt7530: populate lpi_interfaces to fix EEE support

[Andrew Lunn]

On Sat, Aug 22, 2026 at 10:52:51PM +0300, Aleksei Sviridkin wrote:
> mt753x_phylink_get_caps() fills in config->lpi_capabilities and
> config->lpi_timer_default, but never populates config->lpi_interfaces.
> phylink only treats a MAC as supporting phylink managed EEE when the
> tx_lpi methods are implemented and both the LPI capabilities and the
> LPI interfaces are non-empty, so EEE is unavailable on every port:
> 
>   # ethtool --show-eee lan1
>   Cannot get EEE settings: Not supported
> 
> even though the driver implements mac_enable_tx_lpi() and
> mac_disable_tx_lpi() and reads the LPI threshold back out of PMEEECR.
> Since the tx_lpi methods are implemented, phylink takes the other
> branch and calls phy_disable_eee(), which fills eee_disabled_modes, so
> userspace cannot enable EEE either.
> 
> Only the first half of what commit 06dfcd4098cf ("net: dsa: mt7530: fix
> enabling EEE on MT7531 switch on all boards") arranged therefore
> survives. It left EEE off out of the box on purpose, by having
> mt7531_setup() clear the switch PHYs' EEE advertisement, and ended
> "With this change, EEE can now be enabled using ethtool". It cannot be,
> any more.
> 
> Copy the supported interfaces into lpi_interfaces. This requires moving
> the mac_port_get_caps() call ahead of the EEE block, since that is what
> populates supported_interfaces - copying it beforehand would copy an
> empty bitmap.
> 
> LPI stays off by default. The driver does not set eee_enabled_default,
> so phylink leaves tx_lpi_enabled false, and phy_check_link_status()
> computes enable_tx_lpi as tx_lpi_enabled && eee_active - nothing
> asserts LPI until userspace enables it with ethtool --set-eee. The EEE
> advertisement is the part that does change: phylink no longer takes the
> phy_disable_eee() branch, so a PHY that advertises EEE out of reset
> advertises it again and the link may negotiate EEE. MT7531's five
> internal PHYs are the exception, as mt7531_setup() zeroes
> MDIO_AN_EEE_ADV before the switch MDIO bus is registered, so
> phy_probe() reads an empty advertisement and records eee_cfg.eee_enabled
> as false. Nothing does that for an external PHY on port 5 or 6, or on
> the other mt753x variants, EN7528 aside - see below.
> 
> This also makes lpi_capabilities take effect for the first time, so
> correct its value in the same change. PMCR only has force bits for
> 100 Mbps (PMCR_FORCE_EEE100) and 1 Gbps (PMCR_FORCE_EEE1G), and PMSR
> only reports EEE state for those two speeds, so the MAC cannot signal
> LPI at 2.5 Gbps: drop MAC_2500FD. Absence from the header is weak
> evidence on its own, so for what it is worth, the Airoha AN8855 DSA
> driver - posted but not merged [1] - describes a PMCR of the same shape
> that does carry AN8855_PMCR_FORCE_EEE2P5G and AN8855_PMCR_FORCE_EEE5G
> next to the 1 Gbps and 100 Mbps bits. Correcting the value here rather
> than in a separate patch changes nothing observable: while
> lpi_interfaces was empty, lpi_capabilities never reached
> phy->advertising_eee, so no state ever claimed 2.5 Gbps LPI.
> 
> 2500BASE-X has to come out of lpi_interfaces as well, because
> lpi_capabilities cannot express it: it masks the PHY's EEE
> advertisement, a media side property, and never gates LPI activation on
> the MAC side speed. phylink raises the MAC speed to the interface
> maximum when the PHY rate matches (RATE_MATCH_PAUSE in
> phylink_link_up()), so a 1 Gbps media link behind a rate matching 2.5G
> PHY would otherwise arm LPI while the MAC runs at 2.5 Gbps. What that
> costs is limited to setups that keep the MAC on 2500BASE-X, where there
> are no LPI bits to use anyway; a PHY that switches the interface down
> to SGMII or 1000BASE-X keeps LPI, as those stay in the mask.
> 
> For the same reason, skip ports that support neither 100 Mbps nor
> 1 Gbps: on MT7988, EN7581 and AN7583, port 6 is 10 Gbps only, and it
> shares PHY_INTERFACE_MODE_INTERNAL with the 1 Gbps user ports, so the
> interface mask alone cannot tell them apart.
> 
> EEE remains unavailable on EN7528, whose GPHYs do not negotiate it
> reliably. Both LPI bitmaps stay empty there, so phylink keeps taking
> the phy_disable_eee() branch and its advertisement stays off.

This is very verbose. Is it AI generated? Please revise it and make it
suitable for a human. The important part of the commit message is
"Why?", since "What?" can be answered by reading the code.

> - mt753x_phylink_mac_enable_tx_lpi() sets the PMCR force-EEE bits
>   without checking the resolved speed or interface, relying entirely on
>   phylink never calling it above 1 Gbps. A check there would make the
>   driver robust independently of lpi_interfaces being right;
>   deliberately not bundled into a fix.

It is normal to assume phylink is correct. Now, if you do find it
doing the wrong thing, we want to know so we can fix it. So if you do
want to validate it here, make it very noisy if the validation fails.

	
    Andrew

---
pw-bot: cr

Re: [PATCH net 1/2] net: dsa: mt7530: populate lpi_interfaces to fix EEE support

[Aleksei Sviridkin]

> This is very verbose. Is it AI generated? Please revise it and make it
> suitable for a human.

AI assisted, English is not my first language and I lean on it for
prose. The verbosity is my fault though, I reviewed and approved every
word. v2 will carry the Why only and move the mechanism notes below
the scissors.

> It is normal to assume phylink is correct. Now, if you do find it
> doing the wrong thing, we want to know so we can fix it. So if you do
> want to validate it here, make it very noisy if the validation fails.

That note was about a possible defensive check in
mt753x_phylink_mac_enable_tx_lpi(), not something this series adds. If
I ever send it, it will warn loudly.

Re: [PATCH net 2/2] net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support

[Daniel Golle]

Hi Aleksei,

On Sat, Aug 22, 2026 at 10:52:52PM +0300, Aleksei Sviridkin wrote:
> mtk_add_mac() fills in phylink_config.lpi_capabilities and
> phylink_config.lpi_timer_default, but never populates
> phylink_config.lpi_interfaces. phylink only treats a MAC as supporting
> phylink managed EEE when the tx_lpi methods are implemented and both
> the LPI capabilities and the LPI interfaces are non-empty, so EEE is
> unavailable on every MAC that uses mtk_phylink_ops:

Thank you for tracking this down. The missing lpi_interfaces and the
placement after the SoC specific fixups look correct to me, and so
does keeping the xGMII modes out of the mask, given that
mtk_mac_enable_tx_lpi() refuses them.

[...]
> This also makes lpi_capabilities take effect for the first time, so
> correct its value in the same change. MAC_MCR only has EEE force bits
> for 100 Mbps (MAC_MCR_EEE100M) and 1 Gbps (MAC_MCR_EEE1G), and
> MAC_EEECR only carries wakeup times for those two speeds
> (MAC_EEE_WAKEUP_TIME_100, MAC_EEE_WAKEUP_TIME_1000), so the MAC cannot
> signal LPI at 2.5 Gbps: drop MAC_2500FD. Correcting the value here
[...]

This conclusion does not follow from the register layout. MAC_MCR has
no 2.5 Gbps speed setting either: FORCE_SPD is a 2-bit field with
2'b00=10M, 2'b01=100M, 2'b10=1000M and 2'b11 reserved, and SPD_STATUS
in the MAC status register knows the same three speeds (MT7988A
register manual, GMAC chapter, MAC_Px_MCR/MAC_Px_SR). This is why
mtk_gdm_mac_link_up() programs MAC_MCR_SPEED_1000 for SPEED_2500:
2500Base-X on this hardware is 1000Base-X run at 2.5 times the clock,
the MAC operates in its 1000M mode and does not know the difference.
By the same "no bit, hence no support" logic the MAC could not do
2.5 Gbps at all.

FORCE_EEE1G is therefore the bit which would govern LPI on a
2500Base-X link, and whether that works in practice is simply
untested. That was also the assumption in the original submission:
v2 of the EEE patch, before the conversion to phylink managed EEE,
had

		case SPEED_2500:
		case SPEED_1000:
			mcr |= MAC_MCR_EEE1G;

so MAC_2500FD in lpi_capabilities was not an accident [1].

The AN8855 comparison in patch 1/2 points the same way: its PMCR has
a 3-bit FORCE_SPEED field with a discrete 2500 encoding next to
AN8855_PMCR_FORCE_EEE2P5G, while mt753x folds SPEED_2500 (and even
SPEED_10000) onto PMCR_FORCE_SPEED_1000. AN8855 grew per-speed EEE
bits together with per-speed speed encodings; their absence on MT7531
follows from the absent speed encodings and tells us nothing about
LPI in the overclocked 1G mode.

There are still good reasons to leave 2.5 Gbps out for now: MediaTek's
current SDK driver only sets the EEE force bits for 100M and 1G link
speed, EEE signalling on 2500Base-X is outside 802.3, and it is not
documented whether the 1us unit of the wakeup timers still holds with
the port clock at 2.5 times the rate. So I am fine with the resulting
masks in both patches, just please reword "the MAC cannot signal LPI
at 2.5 Gbps" to say unvalidated rather than impossible, in both
commit messages, before someone quotes it as a hardware fact.

If FORCE_EEE1G does work on the overclocked link, the rate matched
EN8811H port from your cover letter would be exactly the setup to
benefit, so this seems worth an experiment at some point.

[1] https://lore.kernel.org/all/20250210125246.1950142-1-dqfext@gmail.com/

Cheers,

Daniel