[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 at 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);
> > +             }
> > +     }
> > +
>