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

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 [off-list ref]:

Hi,

On Tue, Aug 18, 2026 at 09:28:29PM +0300, Vladislav Karmanov wrote:

quoted

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.

quoted

+             /* 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);
+             }
+     }
+