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

[Lad, Prabhakar]

Hi Vladimir,

On Fri, Nov 21, 2025 at 8:48 PM Vladimir Oltean <olteanv@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxx> wrote:
> > >
> > > On Fri, Nov 21, 2025 at 11:35:28AM +0000, Prabhakar wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx>
> > > >
> > > > 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?

The Tagged Frame Format is the same for both the SoCs (like below)
---------------------------------------------------------------------------
7 octets PREAMBLE
1 octet SFD
6 octets DESTINATION ADDRESS
6 octets SOURCE ADDRESS
2 octets ControlTag (default: E001h)
2 octets ControlData
4 octets ControlData2 (timestamp, portmask)
2 octets type/length
0..1500/9000 octets PAYLOAD DATA
0..42 octets PAD
4 octets FRAME CHECK SEQUENCE

Transmit processing (switch to CPU) is different,
On RZ/N1:
ControlData
[0-3] = Port number where the frame was received
[4-15] = reserved

On RZ/T2H:
ControlData
[0-3] = Port number where the frame was received
[4] = Timer used for timestamp
[5] = reserved
[6] = RED period indication
[7-15] = reserved

Also there are differences in receive processing (CPU to switch) the
ControlData and ControlData2 bits differ.

Based on the feedback received I would need to register a new driver.
Do you agree?

Cheers,
Prabhakar