[PATCH net] net: dsa: motorcomm: Clear the MIB buffer on chip reset

[PATCH net] net: dsa: motorcomm: Clear the MIB buffer on chip reset

[David Yang]

.setup() can run again within one registration: removing another switch
from the tree tears the whole tree down, and re-probing sets every
member switch up again. The hardware reset at the start of .setup()
brings the MIB counters back to zero, but a MIB block kept across that
cycle still holds the old software buffer, so the next yt921x_mib_read()
treats the small value as a 32-bit wrap and adds 2^32 to every counter
it extends.

.port_teardown() keeps the MIB block on purpose and .port_setup() only
zeroes a freshly allocated one, so clear the buffer in .setup() together
with the hardware counters it extends. The published stats need no
handling; every entry is republished from the buffer.

Fixes: 186623f4aa72 ("net: dsa: yt921x: Add support for Motorcomm YT921x")
Signed-off-by: David Yang <mmyangfl@gmail.com>
---
 drivers/net/dsa/motorcomm/chip.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/dsa/motorcomm/chip.c b/drivers/net/dsa/motorcomm/chip.c
index 33e5fc127244..ff17233848a8 100644
--- a/drivers/net/dsa/motorcomm/chip.c
+++ b/drivers/net/dsa/motorcomm/chip.c
@@ -2458,6 +2458,16 @@ static int yt921x_dsa_setup(struct dsa_switch *ds)
 		return -ENODEV;
 	}
 
+	for (int port = 0; port < YT921X_PORT_NUM; port++) {
+		struct yt921x_port *pp = &priv->ports[port];
+		struct yt921x_mib *pm = pp->mib;
+
+		if (!pm)
+			continue;
+
+		memset(&pm->data, 0, sizeof(pm->data));
+	}
+
 	mask = priv->info->serdes_mask;
 	for_each_set_bit(port, &mask, YT921X_PORT_NUM) {
 		struct yt921x_port *pp = &priv->ports[port];
-- 
2.53.0

Re: [PATCH net] net: dsa: motorcomm: Clear the MIB buffer on chip reset

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] net: dsa: motorcomm: Clear the MIB buffer on chip reset

[David Yang]

On Mon, Nov 2, 2026 at 6:13 PM <netdev-bot+sinfo@kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.
>
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.

Reported by sashiko

Re: [PATCH net] net: dsa: motorcomm: Clear the MIB buffer on chip reset

[Andrew Lunn]

On Mon, Nov 02, 2026 at 06:20:52PM +0800, David Yang wrote:
> On Mon, Nov 2, 2026 at 6:13 PM <netdev-bot+sinfo@kernel.org> wrote:
> >
> > Hi!
> >
> > This is an automated message. This series looks like a fix, but its
> > commit messages seem to be missing some information:
> >
> >  - How the issue was discovered, e.g. hit in production, hit during
> >    development, syzbot report, manual code inspection, LLM or static
> >    analysis tool scan.
> >
> >  - Whether the issue was actually triggered, or is only theoretical
> >    (e.g. found by code inspection). If it was triggered please include
> >    the symptoms, like the stack trace or error messages.
> >
> > Please do not repost the series just to address the above. Instead,
> > reply to this email with the missing information, so that reviewers
> > can take it into account. If the series needs another revision for
> > other reasons, please include the information in the commit messages
> > then.
> >
> > The evaluation is done by an LLM so it may be wrong, if you think
> > that is the case please reply and explain.
> 
> Reported by sashiko

What is also interesting is that i expect you have tested this on real
hardware, unlike most of the patches we are getting at the moment. It
is worth pointing that out, it might help get your patch merged
faster.

	Andrew

Re: [PATCH net] net: dsa: motorcomm: Clear the MIB buffer on chip reset

[Andrew Lunn]

On Mon, Nov 02, 2026 at 06:11:21PM +0800, David Yang wrote:
> .setup() can run again within one registration: removing another switch
> from the tree tears the whole tree down

Is D in DSA supported by the Motorcomm devices? Or is this tree always
a single node?

> Fixes: 186623f4aa72 ("net: dsa: yt921x: Add support for Motorcomm YT921x")

What i'm trying to understand is, is this theoretical, but never
happens? If so, it should be based on net-next. Or is this an issue
which actually bothers somebody and so is justified having a Fixes:
tag and posted to net?

This is also what that automated email is about. We need information
to decided if the correct tree has been picked. It frequently is wrong
in the LLM age.

   Andrew