From: Simon Horman <horms@kernel.org>
To: bastien.curutchet@bootlin.com
Cc: 'Simon Horman' <horms@kernel.org>,
woojung.huh@microchip.com, UNGLinuxDriver@microchip.com,
andrew@lunn.ch, olteanv@gmail.com, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
maxime.chevallier@bootlin.com, linux@armlinux.org.uk,
pascal.eberhard@se.com, miquel.raynal@bootlin.com,
thomas.petazzoni@bootlin.com, tristram.ha@microchip.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
vladimir.oltean@nxp.com
Subject: Re: [PATCH net-next 9/9] net: dsa: microchip: split ksz_connect_tag_protocol()
Date: Fri, 8 May 2026 13:23:32 +0100 [thread overview]
Message-ID: <20260508122330.1155059-3-horms@kernel.org> (raw)
In-Reply-To: <20260505-clean-ksz-driver-v1-9-05d70fa42461@bootlin.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
Simon says: I also note that there is an AI review of patch 7/9.
However, I believe that is a false positive.
---
net: dsa: microchip: split ksz_connect_tag_protocol()
The commit splits the common ksz_connect_tag_protocol() into switch-specific
operations to ensure each switch only accepts the tag protocol it supports.
> diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
> index 9bac95bb079ff..ac2c63fe0588c 100644
> --- a/drivers/net/dsa/microchip/ksz9477.c
> +++ b/drivers/net/dsa/microchip/ksz9477.c
[ ... ]
> @@ -1624,6 +1625,20 @@ static enum dsa_tag_protocol ksz9477_get_tag_protocol(struct dsa_switch *ds,
> return DSA_TAG_PROTO_KSZ9477;
> }
>
> +static int ksz9477_connect_tag_protocol(struct dsa_switch *ds,
> + enum dsa_tag_protocol proto)
> +{
> + struct ksz_tagger_data *tagger_data;
> +
> + if (proto != DSA_TAG_PROTO_KSZ9893 && proto != DSA_TAG_PROTO_KSZ9477)
> + return -EPROTONOSUPPORT;
Does this fully enforce the restriction mentioned in the commit message?
The commit message states "each switch will only accept to connect the tag
protocol it supports". While ksz88xx_connect_tag_protocol() correctly checks
the chip family, ksz9477_connect_tag_protocol() accepts either
DSA_TAG_PROTO_KSZ9893 or DSA_TAG_PROTO_KSZ9477 without checking the specific
chip ID.
For comparison, ksz9477_get_tag_protocol() returns DSA_TAG_PROTO_KSZ9893 only
for specific chips (KSZ8563, KSZ9893, KSZ9563).
Should this function check dev->chip_id to prevent a chip from being
configured to use the wrong protocol?
> +
> + tagger_data = ksz_tagger_data(ds);
> + tagger_data->xmit_work_fn = ksz_port_deferred_xmit;
> +
> + return 0;
> +}
next prev parent reply other threads:[~2026-05-08 12:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 14:25 [PATCH net-next 0/9] net: dsa: microchip: Remove one indirection layer Bastien Curutchet (Schneider Electric)
2026-05-05 14:25 ` [PATCH net-next 1/9] net: dsa: microchip: Remove unused ksz8_all_queues_split() Bastien Curutchet (Schneider Electric)
2026-05-05 14:25 ` [PATCH net-next 2/9] net: dsa: microchip: remove unused port_cleanup() callback Bastien Curutchet (Schneider Electric)
2026-05-05 14:25 ` [PATCH net-next 3/9] net: dsa: microchip: move KSZ8 ksz_dev_ops to ksz8.c Bastien Curutchet
2026-05-05 14:25 ` [PATCH net-next 4/9] net: dsa: microchip: move KSZ9477 and LAN937 ksz_dev_ops to individual drivers Bastien Curutchet
2026-05-05 14:25 ` [PATCH net-next 5/9] net: dsa: microchip: move phylink_mac_ops " Bastien Curutchet
2026-05-05 14:25 ` [PATCH net-next 6/9] net: dsa: microchip: ensure each ksz_dev_ops has its own dsa_switch_ops Bastien Curutchet
2026-05-05 14:25 ` [PATCH net-next 7/9] net: dsa: microchip: hook up ksz_switch_alloc() to chip-specific dsa_switch_ops Bastien Curutchet
2026-05-05 14:25 ` [PATCH net-next 8/9] net: dsa: microchip: split ksz_get_tag_protocol() Bastien Curutchet
2026-05-05 14:25 ` [PATCH net-next 9/9] net: dsa: microchip: split ksz_connect_tag_protocol() Bastien Curutchet (Schneider Electric)
2026-05-08 12:23 ` Simon Horman [this message]
2026-05-09 2:30 ` [PATCH net-next 0/9] net: dsa: microchip: Remove one indirection layer patchwork-bot+netdevbpf
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=20260508122330.1155059-3-horms@kernel.org \
--to=horms@kernel.org \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=bastien.curutchet@bootlin.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=miquel.raynal@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=pascal.eberhard@se.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=tristram.ha@microchip.com \
--cc=vladimir.oltean@nxp.com \
--cc=woojung.huh@microchip.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