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

[Mieczyslaw Nalewaj <namiltd@yahoo.com>]

On 10/19/2026 4:44 AM, Luiz Angelo Daros de Luca wrote:
>> 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.
[...]
> 
> 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


To answer your question: no, I do not have the Archer AX55 or any other
RTL8367S-VB hardware on my bench, and I have no test environment of my own.
I cannot exercise FDB, VLAN filtering, STP or flooding controls myself.
All testing so far was done by other users who run this code on their
devices, and I depend on their reports.

The code was put together from the Realtek vendor SDK, the existing swconfig
driver code and the help of other contributors. It works on the setups where
it was tested (CPU port over HSGMII, bridge VLAN filtering and per-port
PVIDs), but I could not verify the shared parts against the family D
register layout, and you are right that rtl8365mb_l2.c is untouched.

Without a way to test, I cannot develop this further responsibly. I am
therefore leaving the series as it is for anyone with the hardware and a
proper test setup to pick up, adapt the L2/FDB handling and the remaining
shared code paths, and take it forward. I am happy for others to reuse,
rework or resubmit any part of it.

Best regards,
Mieczyslaw