Netdev List
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: Vladislav Karmanov <vladislav.karmanov.dev@gmail.com>
Cc: netdev@vger.kernel.org, chester.a.unal@arinc9.com,
	dqfext@gmail.com, sean.wang@mediatek.com, andrew@lunn.ch,
	olteanv@gmail.com, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, matthias.bgg@gmail.com,
	angelogioacchino.delregno@collabora.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, yangshiji66@outlook.com
Subject: Re: [PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch
Date: Tue, 18 Aug 2026 19:42:50 +0100	[thread overview]
Message-ID: <aoSnqurLLgdVT_Eu@makrotopia.org> (raw)
In-Reply-To: <20260818182829.1580811-1-vladislav.karmanov.dev@gmail.com>

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


  reply	other threads:[~2026-08-18 18:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 18:28 [PATCH net] net: dsa: mt7530: do not advertise EEE on MT7621 switch Vladislav Karmanov
2026-08-18 18:42 ` Daniel Golle [this message]
2026-08-18 23:22   ` Benjamin Larsson
2026-08-18 19:39 ` 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=aoSnqurLLgdVT_Eu@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=andrew@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chester.a.unal@arinc9.com \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.com \
    --cc=vladislav.karmanov.dev@gmail.com \
    --cc=yangshiji66@outlook.com \
    /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