Re: [PATCH net-next v6 5/9] net: dsa: realtek: rtl8365mb: set and get vlan 4k for family D

From: Linus Walleij

Date: Fri Oct 16 2026 - 16:07:42 EST


On Fri, Oct 16, 2026 at 3:05 AM Mieczyslaw Nalewaj <namiltd@xxxxxxxxx> wrote:

> The hardware structure of 4K VLAN table entries has changed between
> silicon families. Family D's CVLAN entry is two 16-bit words rather
> than three: there is no third word extending member/untag past bit 7,
> and no priority/meter fields at all. The FID field is restricted to a
> narrower 2-bit width. The chip itself supports both IVL and SVL.
> IVL_EN (bit 3) follows vlan4k->ivl_en, as on family C; the only caller,
> rtl8365mb_vlan_4k_port_set(), always requests IVL. SVLAN_CHK_IVL_SVL
> (bit 2) is left at 0, as in the vendor RTL8367D CVLAN API, which sets
> it only from the SVLAN member API; this driver has no SVLAN support.
> vlan4k->ivl_en is read back from IVL_EN.
>
> Reusing the three-word family C layout unconditionally means the third
> word is read from and written back to the register that holds it on
> family C, but does not exist as a distinct table word on family D's
> die; whatever data happens to be there gets folded into member/untag
> bits [10:8] on read, and re-written on every read-modify-write cycle
> in rtl8365mb_vlan_4k_port_set(). Give family D its own two-word
> pack/unpack instead.
>
> The two-word layout matches the vendor switch API for this chip
> family, which writes only 0x0510/0x0511 for a CVLAN entry.
>
> The family D paths are not reachable until the RTL8367S-VB chip table
> entry is added in the last patch of the series.
>
> Signed-off-by: Mieczyslaw Nalewaj <namiltd@xxxxxxxxx>

Looks pretty mechanical and straight-forward.
Reviewed-by: Linus Walleij <linusw@xxxxxxxxxx>

Yours,
Linus Walleij