Re: [net-next PATCH 06/10] net: dsa: realtek: rtl8365mb: add VLAN support

[Linus Walleij]

Hi Luiz, Alvin,

thanks for your patch!

On Wed, Apr 1, 2026 at 1:00 AM Luiz Angelo Daros de Luca
<luizluca@xxxxxxxxx> wrote:

> From: Alvin Šipraga <alsi@xxxxxxxxxxxxxxx>
>
> Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different
> structures for VLANs:
>
> - VLAN4K: A full table with 4096 entries defining port membership and
>   tagging.
> - VLANMC: A smaller table with 32 entries used primarily for PVID
>   assignment.
>
> In this hardware, a port's PVID must point to an index in the VLANMC
> table rather than a VID directly. Since the VLANMC table is limited to
> 32 entries, the driver implements a dynamic allocation scheme to
> maximize resource usage:
>
> - VLAN4K is treated by the driver as the source of truth for membership.
> - A VLANMC entry is only allocated when a port is configured to use a
>   specific VID as its PVID.
> - VLANMC entries are deleted when no longer needed as a PVID by any port.
>
> Although VLANMC has a members field, the switch only checks membership
> in the VLAN4K table. However, when a corresponding VLAN entry also exists
> in VLANMC, this driver keeps both membership configurations in sync.
>
> VLANMC index 0, although a valid entry, is reserved in this driver as a
> neutral PVID value for ports not using a specific PVID.
>
> In the subsequent RTL8367D switch family, VLANMC table was
> removed and PVID assignment was delegated to a dedicated set of
> registers.
>
> All ports start isolated, forwarding exclusively to CPU ports, and
> with VLAN transparent, ignoring VLAN membership. Once a member in a
> bridge, the port isolation is expanded to include the bridge members.
> When that bridge enables VLAN filtering, the VLAN transparent feature is
> disabled, letting the switch filter based on VLAN setup.
>
> Co-developed-by: Alvin Šipraga <alsi@xxxxxxxxxxxxxxx>
> Signed-off-by: Alvin Šipraga <alsi@xxxxxxxxxxxxxxx>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@xxxxxxxxx>

This patch ignores the existing abstractions for generic RTL8366 VLAN
handling in rtl8366-core.c and realtek.h, which is actually compiled
and bundled into the same object with the RTL8365MB driver.
It provides rtl8366_vlan_add(), rtl8366_vlan_del(), rtl8366_enable_vlan(),
rtl8366_enable_vlan4k(), rtl8366_set_pvid(), rtl8366_set_vlan().

The RTL8366RB notably has the same 32 PVID thing and the
same 4K VLAN table.

I understand that it is always easier to develop and test something
for "just this one chip", but I predictably have to be the one to ask
if this can be done in the shared code.

You need to either:

- Take a second sweep and refactor to share the existing VLAN
  handling with RTL8366RB (preferred).

- Explain why RTL8365MB is so very different that it cannot share
  code with RTL8366RB, then proceed to move all code from
  rtl8366-core.c into the RTL8366RB driver, change prefix of functions
  and generally make it local so it doesn't bloat the
  RTL8365MB code before adding this.

Yours,
Linus Walleij