Re: [PATCH net-next v6 0/9] net: dsa: realtek: rtl8365mb: add support for RTL8367S-VB

[Luiz Angelo Daros de Luca]

> This series adds support for the RTL8367S-VB (chip ID 0x6642) to the
> rtl8365mb driver. The chip belongs to a new "family D" that differs from
> the existing family C in its VLAN table layout, speed/RGMII configuration
> and SerDes (SDS13) handling.
>
> Patch 1 documents the chip in the devicetree binding.
> Patch 2 adds the chip family infrastructure (no functional change).
> Patches 3-4 add port speed and RGMII mode configuration for family D.
> Patches 5-6 add VLAN 4k table access and raw-VID PVID handling.
> Patches 7-8 add SDS13 PCS support and re-latching of the SerDes.
> Patch 9 adds the RTL8367S-VB chip table entry. It comes last, so that
> no intermediate commit exposes a family D chip with incomplete
> handling and the series stays bisectable.
>
> Family C's functional behaviour is unchanged. Changes in a shared path
> include a mutex serializing SerDes register access, as well as
> .pcs_disable in pcs_ops and .conduit_state_change in dsa_switch_ops
> (both bail out immediately on family C). The port count is capped at 8
> for family D only (patch 9).
>
> Tested on a TP-Link Archer AX55 v1 (RTL8367S-VB, CPU port over HSGMII
> to an IPQ5018) with bridge VLAN filtering and per-port PVIDs. SGMII has
> also been seen working, but I no longer have the exact link partner and
> speed it was tested with, so treat it as lightly tested. RGMII mode has
> not yet been tested.
>
> Signed-off-by: Mieczyslaw Nalewaj <namiltd@xxxxxxxxx>

Thanks, Mieczyslaw, for working on this series.

Support for Family D is very welcome and increasingly necessary, as Family C
ASICs are no longer being used in new designs. However, the current support
still feels incomplete in critical areas.

When porting a new switch family to rtl8365mb, each feature and hardware table
shared with Family C needs to be verified against the new family's register
layout. In particular, this series leaves rtl8365mb_l2.c untouched, but the L2
table layout in Family D differs from Family C (from memory, the table entry
format is 1 byte shorter and the bitfields are organized differently).

Passing basic traffic in a default router setup can easily give a false sense
of stability because the switch starts forwarding with factory defaults.
However, as soon as DSA attempts to configure FDB entries, dump the L2 table,
or manage multicast groups via bridge operations, the driver will interact with
the L2 table using the wrong layout, causing silent data corruption.

To make Family D truly upstream-ready, we should adapt these shared components
(especially L2/FDB handling) or, at the very least, explicitly return
-EOPNOTSUPP
for unsupported operations so the driver fails gracefully instead of corrupting
hardware state.

In the cover letter, you mentioned the test device. Do you have the Archer AX55
on your own bench now, or were these tests run remotely by users?
Exercising full
DSA functionality (FDB add/del/dump, VLAN filtering, STP, flooding controls)
usually requires a dedicated local test setup where you can generate, sniff,
and inspect traffic directly.

Best regards,

Luiz