[PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch

[PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch

[Vladislav Karmanov]

From: Shiji Yang <yangshiji66@outlook.com>
Date: Sat, 28 Mar 2026 23:29:56 +0800

There are hardware defects in the MT7621 (MT7530) EEE support: with EEE
advertised, some link partners cannot establish a stable connection.
Notably, on a 2-pair (4-wire) cable where both ends advertise gigabit,
1000BASE-T training cannot succeed, and instead of falling back to
100 Mbps the port flaps in a loop and no link/DHCP lease is obtained.
This is confined to the WAN / phylib bring-up path; the DSA/LAN side on
the same device is unaffected.

The MT7530 internal GE PHY advertises EEE by hardware default. The
eee-broken-100tx / eee-broken-1000t device-tree properties only take
effect during the late PHY config_init path, which is too late for these
link partners: they negotiate EEE before the OS disables it and then
fail to fall back cleanly.

Commit af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE
advertisement") removed the early EEE-advertisement disable from
mtk_gephy_config_init(), on the rationale that "disabling EEE
advertisement before the PHY driver initialises keeps it off", i.e. that
the DSA subdriver already performs that early disable. That rationale
holds for MT7531, whose mt7531_setup() clears MDIO_AN_EEE_ADV on each
switch PHY -- but it does not hold for MT7621, whose mt7530_setup()
never had such a loop. So af3b4b0e59de removed the only early EEE
disable that covered MT7621, reintroducing the flapping on MT7621-based
boards (regression reported on ramips/mt7621).

MediaTek's own recommendation (Landen Chao, 2021) confirms the hardware
is the root cause: "EEE of the 10-year-old MT7530 internal gephy has many
IOT problems, so it is recommended to disable its EEE."

Restore the early disable for MT7621, but on the DSA side -- exactly the
location af3b4b0e59de assumed it already lived -- by clearing
MDIO_AN_EEE_ADV on each switch PHY in mt7530_setup(), guarded on
priv->id == ID_MT7621, mirroring the existing mt7531_setup() loop.
Auto-negotiation then falls back to a stable 100 Mbps link instead of
hanging at gigabit.

Tested on ASUS RT-AX53U (MT7621): a single clean
"Link is Up - 100Mbps/Full - flow control off" + DHCP lease on a 2-pair
cable, where the unpatched driver loops. Confirmed on kernel 6.12 and
6.18; also confirmed on Netgear R6220 and EdgeRouter-X (both MT7621).

Fixes: af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement")
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Signed-off-by: Vladislav Karmanov <vladislav.karmanov.dev@gmail.com>
---
 drivers/net/dsa/mt7530.c | 9 +++++++++
 1 file changed, 9 insertions(+)

--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2518,6 +2518,15 @@
 	if ((val & MT7530_XTAL_MASK) == MT7530_XTAL_40MHZ)
 		mt7530_pll_setup(priv);
 
+	if (priv->id == ID_MT7621) {
+		/* Disable EEE advertisement on the switch PHYs. */
+		for (i = MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr);
+		     i < MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr) + MT7530_NUM_PHYS;
+		     i++) {
+			mt7530_phy_write_c45(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
+		}
+	}
+
 	mt753x_trap_frames(priv);
 
 	/* Enable and reset MIB counters */

Re: [PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch

[Daniel Golle]

Hi,

On Tue, Aug 18, 2026 at 09:28:29PM +0300, Vladislav Karmanov wrote:
> There are hardware defects in the MT7621 (MT7530) EEE support: with EEE
> advertised, some link partners cannot establish a stable connection.
> Notably, on a 2-pair (4-wire) cable where both ends advertise gigabit,
> 1000BASE-T training cannot succeed, and instead of falling back to
> 100 Mbps the port flaps in a loop and no link/DHCP lease is obtained.
> This is confined to the WAN / phylib bring-up path; the DSA/LAN side on
> the same device is unaffected.
> 
> The MT7530 internal GE PHY advertises EEE by hardware default. The
> eee-broken-100tx / eee-broken-1000t device-tree properties only take
> effect during the late PHY config_init path, which is too late for these
> link partners: they negotiate EEE before the OS disables it and then
> fail to fall back cleanly.
> 
> Commit af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE
> advertisement") removed the early EEE-advertisement disable from
> mtk_gephy_config_init(), on the rationale that "disabling EEE
> advertisement before the PHY driver initialises keeps it off", i.e. that
> the DSA subdriver already performs that early disable. That rationale
> holds for MT7531, whose mt7531_setup() clears MDIO_AN_EEE_ADV on each
> switch PHY -- but it does not hold for MT7621, whose mt7530_setup()
> never had such a loop. So af3b4b0e59de removed the only early EEE
> disable that covered MT7621, reintroducing the flapping on MT7621-based
> boards (regression reported on ramips/mt7621).
> 
> MediaTek's own recommendation (Landen Chao, 2021) confirms the hardware
> is the root cause: "EEE of the 10-year-old MT7530 internal gephy has many
> IOT problems, so it is recommended to disable its EEE."
> [...]
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -2518,6 +2518,15 @@
>  	if ((val & MT7530_XTAL_MASK) == MT7530_XTAL_40MHZ)
>  		mt7530_pll_setup(priv);
>  
> +	if (priv->id == ID_MT7621) {

It'd be very surprising if this limitation doesn't also apply for the
nearly identical decicated MT7530 IC (found eg. on BananaPi R2).

I'd recommend disabling EEE advertisement on MT7621 and MT7530; and I
suspect that some of the older Trendnet/Econet SoCs which share common
linage with the MediaTek's Ethernet switch and PHY designs could also
be affected.

Hence I'd suggest to extend 'struct mt753x_info' with a 'broken_eee'
bool instead of maintining an in-code list of EEE-broken silicon IDs.

> +		/* Disable EEE advertisement on the switch PHYs. */
> +		for (i = MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr);
> +		     i < MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr) + MT7530_NUM_PHYS;
> +		     i++) {
> +			mt7530_phy_write_c45(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
> +		}
> +	}
> +

Re: [PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch

[Andrew Lunn]

On Tue, Aug 18, 2026 at 09:28:29PM +0300, Vladislav Karmanov wrote:
> From: Shiji Yang <yangshiji66@outlook.com>
> Date: Sat, 28 Mar 2026 23:29:56 +0800
> 
> There are hardware defects in the MT7621 (MT7530) EEE support: with EEE
> advertised, some link partners cannot establish a stable connection.
> Notably, on a 2-pair (4-wire) cable where both ends advertise gigabit,
> 1000BASE-T training cannot succeed, and instead of falling back to
> 100 Mbps the port flaps in a loop and no link/DHCP lease is obtained.
> This is confined to the WAN / phylib bring-up path; the DSA/LAN side on
> the same device is unaffected.

Do we know what is broken here? MAC or PHY?

If it is the PHY which is broken, it would be better to put the
workaround into the PHY driver.

	Andrew

Re: [PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch

[Benjamin Larsson]

Hi.

On 18/08/2026 20:42, Daniel Golle wrote:
> Hi,
> 

> 
> It'd be very surprising if this limitation doesn't also apply for the
> nearly identical decicated MT7530 IC (found eg. on BananaPi R2).
> 
> I'd recommend disabling EEE advertisement on MT7621 and MT7530; and I
> suspect that some of the older Trendnet/Econet SoCs which share common
> linage with the MediaTek's Ethernet switch and PHY designs could also
> be affected.

The phy should be similar to Vitesse also.

> 
> Hence I'd suggest to extend 'struct mt753x_info' with a 'broken_eee'
> bool instead of maintining an in-code list of EEE-broken silicon IDs.
> 
>> +		/* Disable EEE advertisement on the switch PHYs. */
>> +		for (i = MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr);
>> +		     i < MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr) + MT7530_NUM_PHYS;
>> +		     i++) {
>> +			mt7530_phy_write_c45(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
>> +		}
>> +	}
>> +
> 
> 

MvH
Benjamin Larsson

Re: [PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch

[Vladislav Karmanov]

Hi Andrew, Hi Daniel,

Thanks for the review.

> Do we know what is broken here? MAC or PHY? If it is the PHY which is
> broken, it would be better to put the workaround into the PHY driver.

It is the PHY that is broken -- the MT7530 internal GE PHY (PHY ID
0x03a29412, driven by mediatek-ge). Landen Chao (MediaTek, 2021) puts the
root cause there: "EEE of the 10-year-old MT7530 internal gephy has many
IOT problems, so it is recommended to disable its EEE."

That would point to the PHY driver as the natural home, but I think the
DSA side is actually the right place, and af3b4b0e59de -- the commit this
patch fixes -- is itself the evidence: it removed the early EEE disable
from mtk_gephy_config_init() on the rationale that the disable done there
"is somehow enabled afterwards", i.e. a PHY-driver-side disable does not
stick (something re-enables EEE advertisement after config_init). What
does stick is the disable done earlier in the DSA setup path -- which is
why MT7531 does it in mt7531_setup() and why af3b4b0e59de considered the
mtk-ge disable redundant for MT7531. The catch is that mt7530_setup()
never had that loop, so MT7621 (and MT7530) lost their only effective
early disable when af3b4b0e59de dropped the mtk-ge one. Putting the
disable back into the PHY driver would reintroduce the "gets re-enabled
afterwards" problem af3b4b0e59de removed it for. So I'd keep it on the
DSA side

> I'd recommend disabling EEE advertisement on MT7621 and MT7530;
> Hence I'd suggest to extend 'struct mt753x_info' with a 'broken_eee'
> bool instead of maintaining an in-code list of EEE-broken silicon IDs.

Agreed on both. ID_MT7530 (the dedicated MT7530 IC, e.g. BananaPi R2)
uses the same mt7530_setup() and the same internal GE PHY, so it should
be covered too. I have prepared  v2 that adds a broken_eee bool to
struct mt753x_info and sets it for ID_MT7621 and ID_MT7530, gating the
MDIO_AN_EEE_ADV clear loop on priv->info->broken_eee instead of the
open-coded ID check.

v2 follows as a fresh thread with a lore link back to v1.

Regarding older Trendnet/Econet SoCs sharing the lineage: I don't have
that hardware, so I'd rather not guess the flag makes it trivial to
extend later if someone with access can confirm

вт, 18 авг. 2026 г. в 21:43, Daniel Golle <daniel@makrotopia.org>:
>
> Hi,
>
> On Tue, Aug 18, 2026 at 09:28:29PM +0300, Vladislav Karmanov wrote:
> > There are hardware defects in the MT7621 (MT7530) EEE support: with EEE
> > advertised, some link partners cannot establish a stable connection.
> > Notably, on a 2-pair (4-wire) cable where both ends advertise gigabit,
> > 1000BASE-T training cannot succeed, and instead of falling back to
> > 100 Mbps the port flaps in a loop and no link/DHCP lease is obtained.
> > This is confined to the WAN / phylib bring-up path; the DSA/LAN side on
> > the same device is unaffected.
> >
> > The MT7530 internal GE PHY advertises EEE by hardware default. The
> > eee-broken-100tx / eee-broken-1000t device-tree properties only take
> > effect during the late PHY config_init path, which is too late for these
> > link partners: they negotiate EEE before the OS disables it and then
> > fail to fall back cleanly.
> >
> > Commit af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE
> > advertisement") removed the early EEE-advertisement disable from
> > mtk_gephy_config_init(), on the rationale that "disabling EEE
> > advertisement before the PHY driver initialises keeps it off", i.e. that
> > the DSA subdriver already performs that early disable. That rationale
> > holds for MT7531, whose mt7531_setup() clears MDIO_AN_EEE_ADV on each
> > switch PHY -- but it does not hold for MT7621, whose mt7530_setup()
> > never had such a loop. So af3b4b0e59de removed the only early EEE
> > disable that covered MT7621, reintroducing the flapping on MT7621-based
> > boards (regression reported on ramips/mt7621).
> >
> > MediaTek's own recommendation (Landen Chao, 2021) confirms the hardware
> > is the root cause: "EEE of the 10-year-old MT7530 internal gephy has many
> > IOT problems, so it is recommended to disable its EEE."
> > [...]
> > --- a/drivers/net/dsa/mt7530.c
> > +++ b/drivers/net/dsa/mt7530.c
> > @@ -2518,6 +2518,15 @@
> >       if ((val & MT7530_XTAL_MASK) == MT7530_XTAL_40MHZ)
> >               mt7530_pll_setup(priv);
> >
> > +     if (priv->id == ID_MT7621) {
>
> It'd be very surprising if this limitation doesn't also apply for the
> nearly identical decicated MT7530 IC (found eg. on BananaPi R2).
>
> I'd recommend disabling EEE advertisement on MT7621 and MT7530; and I
> suspect that some of the older Trendnet/Econet SoCs which share common
> linage with the MediaTek's Ethernet switch and PHY designs could also
> be affected.
>
> Hence I'd suggest to extend 'struct mt753x_info' with a 'broken_eee'
> bool instead of maintining an in-code list of EEE-broken silicon IDs.
>
> > +             /* Disable EEE advertisement on the switch PHYs. */
> > +             for (i = MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr);
> > +                  i < MT753X_CTRL_PHY_ADDR(priv->mdiodev->addr) + MT7530_NUM_PHYS;
> > +                  i++) {
> > +                     mt7530_phy_write_c45(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV, 0);
> > +             }
> > +     }
> > +
>

Re: [PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch

[Andrew Lunn]

On Thu, Aug 20, 2026 at 11:18:23PM +0300, Vladislav Karmanov wrote:
> Hi Andrew, Hi Daniel,
> 
> Thanks for the review.
> 
> > Do we know what is broken here? MAC or PHY? If it is the PHY which is
> > broken, it would be better to put the workaround into the PHY driver.
> 
> It is the PHY that is broken -- the MT7530 internal GE PHY (PHY ID
> 0x03a29412, driven by mediatek-ge). Landen Chao (MediaTek, 2021) puts the
> root cause there: "EEE of the 10-year-old MT7530 internal gephy has many
> IOT problems, so it is recommended to disable its EEE."
> 
> That would point to the PHY driver as the natural home, but I think the
> DSA side is actually the right place,

There are a couple of parts to disabling EEE.

In this case, you need to disable advertise early. So the PHY probe()
would be the correct place to do this.

You also needs to let phylib know that EEE is broken. So the PHY
driver should be calling phy_disable_eee(). That will prevent the user
from turning EEE back on again.

Since it is the PHY which is broken, this will cover all usage of the
PHY, be it integrated in a switch, or standalone.

     Andrew