Re: [PATCH net-next 02/11] net: dsa: tag_rzn1_a5psw: Add RZ/T2H ETHSW tag protocol and register ethsw tag driver

Vladimir Oltean
2025-11-21T20:48:39Z

On Fri, Nov 21, 2025 at 08:29:04PM +0000, Lad, Prabhakar wrote:
> On Fri, Nov 21, 2025 at 7:27 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> >
> > On Fri, Nov 21, 2025 at 11:35:28AM +0000, Prabhakar wrote:
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > Add an explicit tag protocol for the RZ/T2H ETHSW and register a separate
> > > ethsw tag driver so the existing A5PSW tag implementation can be reused
> > > for RZ/T2H without code duplication.
> > >
> > > The ETHSW IP on RZ/T2H shares substantial commonality with the A5PSW IP on
> > > RZ/N1, and the current tag driver does not touch the register fields that
> > > differ between the two blocks.
> >
> > Tagging protocol drivers are specifically written to not deal with
> > register fields. I would like a clarification that this is a phrasing
> > mistake and you mean the packet header fields that differ between the
> > ETHSW and the A5PSW tag format.
> >
> Unlike the other drivers, tagging drivers don't have compatible
> strings to match against. For the ETHSW IP, the current driver is
> reused as-is. My intention with the comment was simply to point out
> that, if an issue ever arises that requires us to split the paths, we
> can future-proof things by using DSA_TAG_PROTO_* identifiers.

The tagging protocol's name uniquely defines the layout of the DSA
header and general interaction procedure required on RX and TX (for more
complex things such as PTP). It doesn't have to be further namespaced by
its users just because. In other words, two switch drivers using the
same tagging protocol with the same name is fine (even if due to a lack
of imagination, the tagging protocol's name comes just from its first
user), and introducing a new name for it would be unnecessary. For
example, felix_vsc9959.c, a switch different from ocelot_ext.c, uses
DSA_TAG_PROTO_OCELOT because the protocol is identical.

The exception would be when there exist packet headers which have
different layouts - then irrespective of whether those fields are
currently used or not, we should register a new driver. This is the
only thing that matters. I thought that you were saying that such
differences exist, but after your second reply, it seems not?