Re: [PATCH net] net: dsa: b53: be VLAN unaware when not filtering

[Vladimir Oltean <olteanv@gmail.com>]

On Wed, Aug 05, 2026 at 09:44:51AM +0200, Jonas Gorski wrote:
> Unfortunately what this does is break modifying ARL entries with VID
> != 0, which is why I haven't added this.
> 
> While SVL is active, any ARL add/remove operations ignore the VID
> field/register and force it to 0, making existing static ARL entries
> with VID != 0 inaccessible, and any (static) ARL entries added will
> have their VID set to 0, regardless what the software entry said.
> 
> This causes the ARL hardware table to go out of sync with the bridge
> fdb/mdb software tables, and will lead to potentially hard to debug
> network issues.
> 
> The options to remedy this are:
> 
> 1. keep track of all static fdb (and mdb) entries added to the
> hardware table, so we "sync" it on switching vlan filtering on/off (or
> find a way to do so without having a copy), or
> 2. while vlan filtering is off, have static vlan table entries for all
> possible VIDs, or
> 3. use direct memory access registers to directly modify the ARL table
> memory instead of going through default registers while SVL is
> enabled.
> 
> Neither one is a quick and easy fix.
> 
> 1/2 make switching vlan filtering likely a costly operation (I test
> implemented 2, and it takes several seconds for SPI connected switches
> - not sure if this is acceptable). 3 requires knowing the in-memory
> formats for each switch chip, which aren't publicly documented.
> 
> Best regards,
> Jonas

I think the only reliable way to fix VLAN unaware mode in a way that's
portable across all b53 variants is a variant of this patch: allow
802.1Q mode to be disabled. Then we need to deal with the fallout caused
by it upon the ARL.

1. This looks implementable with some complexity isolated within the b53
   driver:
   - on any .port_fdb_add(), .port_fdb_del(), .port_mdb_add(), .port_mdb_del(),
     compare the VID of the entry with the dev->vlan_enabled state.
     - if VID != 0 and dev->vlan_enabled, or if VID == 0 and !dev->vlan_enabled,
       commit the operation directly to the ARL, as is currently done
     - if VID == 0 and !dev->vlan_enabled, or if VID != 0 and dev->vlan_enabled,
       operate on a software list, allocating, deleting or modifying a
       local representation of the ARL entry
   - on vlan_filtering toggles from 0 to 1 or from 1 to 0, acquire
     dev->arl_mutex and flush out all static and dynamic ARL entries
     across the entire switch, commit the static ones from the software
     list and clear the software list
   - dev->vlan_enabled will probably need to be merged with
     dev->vlan_filtering, since the vlan_enabled=1 vlan_filtering=0 case
     is broken

2. I see bcm_sf2 has support for B53_JOIN_ALL_VLAN_EN; IIUC this
   proposal is a soft emulation of that. Would it work though? 2 concerns:
   - in b53_switch_chips[] I see not all switches have a full 4K VLAN table
   - unless b53 has a feature equivalent to MV88E6XXX_G1_VTU_DATA_MEMBER_TAG_UNMODIFIED
     rather than the port-wide vl->untag, the emulation would either push a
     VLAN tag in originally untagged frames, or strip a VLAN tag from
     previously VLAN tagged frames. Neither option fits the bill for
     what vlan_filtering=0 semantics expect (ignore the tag).

3. From a distance it doesn't sound bad, but I cannot comment on the
   feasibility of this and the scalability across the 4 b53_arl_ops;
   maybe Florian can.

The big advantage of option #1 is that it shouldn't depend on any HW
functionality which is only present on some silicon variants. I don't
see any downside except for the higher SW complexity in the control path.

We could also discuss falling back to software bridging for the
vlan_filtering=0 case, but that penalizes the data path, so it would
probably not be the option of choice.