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. Expose a distinct DSA protocol and a second
dsa_device_ops to let consumers select the RZ/T2H tag format while keeping
the proven A5PSW handling unchanged.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
include/net/dsa.h | 2 ++
include/uapi/linux/if_ether.h | 2 +-
net/dsa/tag_rzn1_a5psw.c | 21 +++++++++++++++++++--
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 97d5f401cfcf..81302315e493 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -57,6 +57,7 @@ struct tc_action;
#define DSA_TAG_PROTO_BRCM_LEGACY_FCS_VALUE 29
#define DSA_TAG_PROTO_YT921X_VALUE 30
#define DSA_TAG_PROTO_MXL_GSW1XX_VALUE 31
+#define DSA_TAG_PROTO_RZT2H_ETHSW_VALUE 32
enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE = DSA_TAG_PROTO_NONE_VALUE,
@@ -91,6 +92,7 @@ enum dsa_tag_protocol {
DSA_TAG_PROTO_VSC73XX_8021Q = DSA_TAG_PROTO_VSC73XX_8021Q_VALUE,
DSA_TAG_PROTO_YT921X = DSA_TAG_PROTO_YT921X_VALUE,
DSA_TAG_PROTO_MXL_GSW1XX = DSA_TAG_PROTO_MXL_GSW1XX_VALUE,
+ DSA_TAG_PROTO_RZT2H_ETHSW = DSA_TAG_PROTO_RZT2H_ETHSW_VALUE,
};
struct dsa_switch;
diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h
index 2c93b7b731c8..61f64cb38b08 100644
--- a/include/uapi/linux/if_ether.h
+++ b/include/uapi/linux/if_ether.h
@@ -118,7 +118,7 @@
#define ETH_P_YT921X 0x9988 /* Motorcomm YT921x DSA [ NOT AN OFFICIALLY REGISTERED ID ] */
#define ETH_P_EDSA 0xDADA /* Ethertype DSA [ NOT AN OFFICIALLY REGISTERED ID ] */
#define ETH_P_DSA_8021Q 0xDADB /* Fake VLAN Header for DSA [ NOT AN OFFICIALLY REGISTERED ID ] */
-#define ETH_P_DSA_A5PSW 0xE001 /* A5PSW Tag Value [ NOT AN OFFICIALLY REGISTERED ID ] */
+#define ETH_P_DSA_A5PSW 0xE001 /* A5PSW/ETHSW Tag Value [ NOT AN OFFICIALLY REGISTERED ID ] */
#define ETH_P_IFE 0xED3E /* ForCES inter-FE LFB type */
#define ETH_P_AF_IUCV 0xFBFB /* IBM af_iucv [ NOT AN OFFICIALLY REGISTERED ID ] */
diff --git a/net/dsa/tag_rzn1_a5psw.c b/net/dsa/tag_rzn1_a5psw.c
index 201782b4f8dc..66619986fa71 100644
--- a/net/dsa/tag_rzn1_a5psw.c
+++ b/net/dsa/tag_rzn1_a5psw.c
@@ -23,6 +23,7 @@
*/
#define A5PSW_NAME "a5psw"
+#define ETHSW_NAME "ethsw"
#define A5PSW_TAG_LEN 8
#define A5PSW_CTRL_DATA_FORCE_FORWARD BIT(0)
@@ -108,8 +109,24 @@ static const struct dsa_device_ops a5psw_netdev_ops = {
.rcv = a5psw_tag_rcv,
.needed_headroom = A5PSW_TAG_LEN,
};
+MODULE_ALIAS_DSA_TAG_DRIVER(DSA_TAG_PROTO_A5PSW, A5PSW_NAME);
+DSA_TAG_DRIVER(a5psw_netdev_ops);
+
+static const struct dsa_device_ops ethsw_netdev_ops = {
+ .name = ETHSW_NAME,
+ .proto = DSA_TAG_PROTO_RZT2H_ETHSW,
+ .xmit = a5psw_tag_xmit,
+ .rcv = a5psw_tag_rcv,
+ .needed_headroom = A5PSW_TAG_LEN,
+};
+MODULE_ALIAS_DSA_TAG_DRIVER(DSA_TAG_PROTO_RZT2H_ETHSW, ETHSW_NAME);
+DSA_TAG_DRIVER(ethsw_netdev_ops);
+
+static struct dsa_tag_driver *dsa_tag_driver_array[] = {
+ &DSA_TAG_DRIVER_NAME(a5psw_netdev_ops),
+ &DSA_TAG_DRIVER_NAME(ethsw_netdev_ops),
+};
+module_dsa_tag_drivers(dsa_tag_driver_array);
MODULE_DESCRIPTION("DSA tag driver for Renesas RZ/N1 A5PSW switch");
MODULE_LICENSE("GPL v2");
-MODULE_ALIAS_DSA_TAG_DRIVER(DSA_TAG_PROTO_A5PSW, A5PSW_NAME);
-module_dsa_tag_driver(a5psw_netdev_ops);
--
2.52.0On 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. > Expose a distinct DSA protocol and a second dsa_device_ops to let > consumers select the RZ/T2H tag format while keeping the proven A5PSW > handling unchanged. > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> > ---
Hi Vladimir, Thank you for the review. 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. Cheers, Prabhakar
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?
Hi Vladimir, On Fri, Nov 21, 2025 at 8:48 PM Vladimir Oltean <olteanv@gmail.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@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? 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
On Fri, Nov 21, 2025 at 09:30:14PM +0000, Lad, Prabhakar wrote: > Based on the feedback received I would need to register a new driver. > Do you agree? I agree, but this justification needs to be present in the commit message.
© 2016 - 2026 Red Hat, Inc.