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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+V-a8uA-p9wGXNVdf8Oykt518_2X6fyK6s2-R+G_AR2DqXckA@mail.gmail.com>
Date: Fri, 21 Nov 2025 21:30:14 +0000
From: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Clément Léger <clement.leger@...tlin.com>, 
	Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Simon Horman <horms@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>, 
	Russell King <linux@...linux.org.uk>, Geert Uytterhoeven <geert+renesas@...der.be>, 
	Magnus Damm <magnus.damm@...il.com>, linux-renesas-soc@...r.kernel.org, 
	netdev@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Biju Das <biju.das.jz@...renesas.com>, 
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, 
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH net-next 02/11] net: dsa: tag_rzn1_a5psw: Add RZ/T2H ETHSW
 tag protocol and register ethsw tag driver

Hi Vladimir,

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

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