Re: [PATCH net v2 2/2] net: dsa: realtek: rtl8365mb: keep the neutral PVID in VLAN-unaware bridges

[Stijn Cleynhens <stijncleynhens@gmail.com>]

On Tue, 10 Nov 2026 15:21:01 +0000 netdev-bot+sashiko@kernel.org wrote:
> - [High] In VLAN-unaware bridges, rtl8365mb_port_commit_pvid() now sets
>   pvid = 0 (VLANMC index 0, EVID 0).

Jakub, as you asked for a reply: the review is correct. Multicast
entries have no EFID, so with all VLAN-unaware bridges and standalone
ports classified to VID 0 and VID 0 in IVL, they share one {MAC, VID 0}
entry. v3 will not do that.

Luiz, this ties in with your mail. One correction first: the patch
does not move ports without a PVID to the bridge PVID, it does the
reverse, it keeps the neutral PVID on the ports of a VLAN-unaware
bridge. Your main point stands though, and I tested the SVL direction
on hardware.

The switch has a port-based FID (enable mask at 0x07ac, one FID per
port from 0x07ad). I tried it on an RTL8367S and on an RTL8367S-VB, the
latter with the L2 entry layout from Mieczyslaw's v10:

 - The port-based FID alone changes nothing while the VLAN4k entry of
   the VLAN a frame is classified to has IVL set. The learned key
   stays {MAC, VID}.

 - With that VLAN4k entry in SVL, the learned key is {MAC, FID}, and
   the FID is the one of the ingress port, not the one in the VLAN4k
   entry.

 - A static unicast entry written as SVL with the port's FID replaces
   the learned one in place. The roaming case from the commit message
   passes, 10 of 10 pings, on both chips.

 - Multicast entries follow the port's FID as well. With an SVL entry
   whose only member is an unused port, 0 of about 40 frames reached
   the CPU while the ingress port had the entry's FID, and 38 (39 on
   the VB) once I gave the port another FID.

 - Two VLAN-unaware bridges on the RTL8367S, each with its own FID: the
   same MAC and the same group in both give separate entries, deleting
   the group in one bridge leaves the other's entry alone, and traffic
   of one bridge does not hit the entry of the other.

 - Tagged frames, on both chips: with the VLAN4k entry of VLAN 20 in
   SVL, a station sending in VLAN 20 is learned as {MAC, port FID} and
   the roaming case passes, 10 of 10. With the entry in IVL as today it
   fails, 0 of 10.

So for v3 I would drop patch 1, leave VLAN 0 in SVL, and:

 - give each VLAN-unaware bridge its own FID and enable it on the
   ports of the bridge while they do not filter,
 - keep the neutral PVID on those ports, as patch 2 does now, so that
   untagged frames are classified to a VLAN in SVL,
 - write the VID 0 FDB and MDB entries from DSA as SVL with the FID of
   the bridge,
 - as a separate patch, write a VLAN4k entry as IVL only while one of
   its member ports filters, and as SVL otherwise, so that tagged
   frames in a VLAN-unaware bridge are looked up by MAC as well.

VID 0 is then no longer part of any lookup key, and multicast is
separated per bridge by the FID. vlan_filtering_is_global is not
needed. What remains is a VLAN that a filtering and a non-filtering
bridge on the same switch both use: it stays in IVL.

The FID is 4 bits on the RTL8367S and 2 bits on the VB, which limits
the number of such bridges.

Does this direction work for you? As this is no longer a small fix, I
will send v3 for net-next, keeping the Fixes tag, unless you prefer it
in net.

pw-bot: cr

Stijn