From: netdev-bot+sashiko@kernel.org
To: gongtao0607@gmail.com
Cc: netdev@vger.kernel.org, chester.a.unal@arinc9.com,
daniel@makrotopia.org, 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, lorenzo@kernel.org,
arinc.unal@arinc9.com, florian.fainelli@broadcom.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
lorenzo.bianconi@oss.qualcomm.com
Subject: Re: [PATCH net v2 2/2] net: dsa: mt7530: trap frames to conduit in MFC on EN7581 and AN7583
Date: Sun, 27 Sep 2026 06:06:26 +0000 [thread overview]
Message-ID: <179048918667.2160803.15824370089117155993@kernel.org> (raw)
In-Reply-To: <20260923055103.949540-3-gongtao0607@gmail.com>
Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.
Low priority / nit picks for your consideration:
- [Low] The patch fixes the same missing MFC CPU_EN/CPU_PORT programming
on two switch variants, but the Fixes: tag names only the EN7581…
- [Low] After this patch, the comments no longer match the code for
EN7581/AN7583.
Pre-existing issues:
- [Medium] This problem wasn't introduced by this patch, but port
mirroring on AN7583 writes the wrong bit.
--
net: dsa: mt7530: trap frames to conduit in MFC on EN7581 and AN7583
On EN7581 and AN7583, setting the MT7531_CFC CPU_PMAP bitmap by itself
does not get trapped control frames to the CPU port. This patch adds
ID_EN7581 and ID_AN7583 to mt753x_conduit_state_change(). MT7530_CPU_EN
and MT7530_CPU_PORT in MT753X_MFC are then programmed when the conduit
becomes operational.
> Fixes: 2b0229f67932 ("net: dsa: mt7530: Add EN7581 support")
[Severity: Low]
Should there also be a Fixes tag for the AN7583 commit?
2b0229f67932 did not add ID_AN7583. It was added by d76556db10bf41
("net: dsa: mt7530: Add AN7583 support"), and that commit added AN7583
with the same missing MFC programming.
Stable trees that have 2b0229f67932 but not d76556db10bf41 have no
ID_AN7583. The AN7583 half of the check in mt753x_conduit_state_change()
can't be applied there as written.
Perhaps something like:
Fixes: d76556db10bf ("net: dsa: mt7530: Add AN7583 support")
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 20bb07fac0f7b..92b5e949ffab7 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -3338,7 +3338,8 @@ mt753x_conduit_state_change(struct dsa_switch *ds,
> * interface is up.
> */
> if (priv->id != ID_MT7530 && priv->id != ID_MT7621 &&
> - priv->id != ID_EN7528)
> + priv->id != ID_EN7528 &&
> + priv->id != ID_EN7581 && priv->id != ID_AN7583)
> return;
[Severity: Low]
This isn't a bug, but should the comments be updated now that this check
also covers EN7581 and AN7583?
The comment above this check still mentions only MT7530:
/* Set the CPU port to trap frames to for MT7530. Trapped frames will be
* forwarded to the numerically smallest CPU port whose conduit
* interface is up.
*/
The comment in mt753x_cpu_port_enable() says the CFC CPU_PMAP bitmap
chooses the trap destination. Its check also includes EN7581 and AN7583:
/* Add the CPU port to the CPU port bitmap for MT7531 and the switch on
* the MT7988 SoC. Trapped frames will be forwarded to the CPU port that
* is affine to the inbound user port.
*/
if (priv->id == ID_MT7531 || priv->id == ID_MT7988 ||
priv->id == ID_EN7581 || priv->id == ID_AN7583)
mt7530_set(priv, MT7531_CFC, MT7531_CPU_PMAP(BIT(port)));
The two comments now describe different forwarding rules for the same
chips. Neither one says that EN7581 and AN7583 need both registers, or
which register chooses the destination.
[Severity: Medium]
This is a pre-existing issue and was not introduced by this patch. Looking
at the AN7583 handling, MT753X_MIRROR_EN() in mt7530.h seems to be missing
ID_AN7583:
drivers/net/dsa/mt7530.h:
#define MT753X_MIRROR_EN(id) ((id == ID_MT7531 || \
id == ID_MT7988 || \
id == ID_EN7581) ? \
MT7531_MIRROR_EN : MT7530_MIRROR_EN)
MT753X_MIRROR_REG() and the MT753X_MIRROR_PORT_*() macros do include
ID_AN7583. On AN7583 the register is therefore MT7531_CFC, but the enable
bit is MT7530_MIRROR_EN (BIT(3)). That bit is inside MT7531_CPU_PMAP_MASK
(GENMASK(7, 0)).
Does mt753x_port_mirror_add() then add port 3 to the CPU port bitmap for
trapped frames, instead of enabling mirroring?
val = mt7530_read(priv, MT753X_MIRROR_REG(priv->id));
...
val |= MT753X_MIRROR_EN(priv->id);
...
mt7530_write(priv, MT753X_MIRROR_REG(priv->id), val);
MT7531_MIRROR_EN (BIT(19)) is never set, so mirroring would not work on
AN7583. The -EEXIST check in mt753x_port_mirror_add() also tests the wrong
bit.
When the last mirror is removed, mt753x_port_mirror_del() does this:
val &= ~MT753X_MIRROR_EN(priv->id);
That clears CPU_PMAP bit 3 in MT7531_CFC, not the mirror enable bit.
This seems to go back to d76556db10bf41 ("net: dsa: mt7530: Add AN7583
support"). Adding ID_AN7583 to MT753X_MIRROR_EN() would fix it.
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260923055103.949540-1-gongtao0607%40gmail.com
prev parent reply other threads:[~2026-09-27 6:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 5:51 [PATCH net v2 0/2] net: dsa: mt7530: fix trapped frame forwarding and egress tagging Tao Gong
2026-09-23 5:51 ` [PATCH net v2 1/2] net: dsa: mt7530: use consistent egress tag for trapped link-local frames Tao Gong
2026-09-27 6:06 ` netdev-bot+sashiko
2026-09-23 5:51 ` [PATCH net v2 2/2] net: dsa: mt7530: trap frames to conduit in MFC on EN7581 and AN7583 Tao Gong
2026-09-27 6:06 ` netdev-bot+sashiko [this message]
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=179048918667.2160803.15824370089117155993@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=arinc.unal@arinc9.com \
--cc=chester.a.unal@arinc9.com \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=gongtao0607@gmail.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=lorenzo.bianconi@oss.qualcomm.com \
--cc=lorenzo@kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.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
all inboxes | Powered by JetHome®