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

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

[Semih Baskan]

b53 keeps the VLAN table enabled at all times, so a tagged frame whose VID
is not in the table resolves to an empty member set and is dropped before
it reaches the CPU. Documentation/networking/switchdev.rst requires a
standalone port to keep every VLAN configured on top of it working, and a
port that is not filtering to forward frames whose VID is absent from the
table.

Turn the table off in that case. It also selects shared VLAN learning,
which b53_arl_rw_op() already ties to the same flag. Switches with no tag
protocol keep the CPU port tagged in every VLAN and identify the source
port from that tag, so they stay VLAN aware.

b53_configure_vlan() has to stop passing dev->vlan_enabled back in as the
requested state. b53_enable_vlan() stores its result there, so the disabled
state latches and enabling VLAN filtering later would not re-enable the
table.

An 8021q upper on a standalone port is the case that breaks, for example a
PPPoE WAN on VLAN 35. The PADO comes back tagged and is dropped, so no
session comes up and there is no default route.

Tested on an Asus RT-N18U (BCM53011 rev 5) against a PPPoE concentrator on
a VLAN 35 subinterface. pppd timed out waiting for PADO before, and the
session establishes after. With VLAN filtering enabled the table is still
programmed and still enforces port membership.

Fixes: 06cfb2df7eb0 ("net: dsa: don't advertise 'rx-vlan-filter' when not needed")
Cc: stable@vger.kernel.org
Signed-off-by: Semih Baskan <strst.gs@gmail.com>
---
I tried setting ds->needs_standalone_vlan_filtering on hardware first. It is
not sufficient on b53: f089652b6b16 ("net: dsa: b53: do not program vlans
when vlan filtering is off") makes .port_vlan_add return before the hardware
write while filtering is off, so the VID still never reaches the table.
rx-vlan-filter flipped to on and tagged frames were still dropped, 0 of 5.

Relaxing that check instead also works, but only together with the opt-in
above, since without the feature bit 8021q never calls .port_vlan_add at
all. Making the port VLAN unaware follows the same switchdev rule that
commit cites.

I also checked the case where another bridge on the same chip has
vlan_filtering=1, since b53 sets vlan_filtering_is_global. DSA offloads the
uppers on the standalone port too, so rx-vlan-filter goes on there and the
tagged frames keep arriving. This patch cannot execute in that state.

 drivers/net/dsa/b53/b53_common.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 3f5b9592794d..76378afe4993 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -385,6 +385,9 @@ static void b53_enable_vlan(struct b53_device *dev, int port, bool enable,
 {
 	u8 mgmt, vc0, vc1, vc4 = 0, vc5;
 
+	if (!enable_filtering && dev->tag_protocol != DSA_TAG_PROTO_NONE)
+		enable = false;
+
 	b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
 	b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL0, &vc0);
 	b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL1, &vc1);
@@ -916,7 +919,7 @@ int b53_configure_vlan(struct dsa_switch *ds)
 		b53_do_vlan_op(dev, VTA_CMD_CLEAR);
 	}
 
-	b53_enable_vlan(dev, -1, dev->vlan_enabled, dev->vlan_filtering);
+	b53_enable_vlan(dev, -1, true, dev->vlan_filtering);
 
 	/* Create an untagged VLAN entry for the default PVID in case
 	 * CONFIG_VLAN_8021Q is disabled and there are no calls to

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

[Jonas Gorski]

Hi,

On Wed, Aug 5, 2026 at 9:27 AM Semih Baskan <strst.gs@gmail.com> wrote:
>
> b53 keeps the VLAN table enabled at all times, so a tagged frame whose VID
> is not in the table resolves to an empty member set and is dropped before
> it reaches the CPU. Documentation/networking/switchdev.rst requires a
> standalone port to keep every VLAN configured on top of it working, and a
> port that is not filtering to forward frames whose VID is absent from the
> table.
>
> Turn the table off in that case. It also selects shared VLAN learning,
> which b53_arl_rw_op() already ties to the same flag. Switches with no tag
> protocol keep the CPU port tagged in every VLAN and identify the source
> port from that tag, so they stay VLAN aware.
>
> b53_configure_vlan() has to stop passing dev->vlan_enabled back in as the
> requested state. b53_enable_vlan() stores its result there, so the disabled
> state latches and enabling VLAN filtering later would not re-enable the
> table.
>
> An 8021q upper on a standalone port is the case that breaks, for example a
> PPPoE WAN on VLAN 35. The PADO comes back tagged and is dropped, so no
> session comes up and there is no default route.
>
> Tested on an Asus RT-N18U (BCM53011 rev 5) against a PPPoE concentrator on
> a VLAN 35 subinterface. pppd timed out waiting for PADO before, and the
> session establishes after. With VLAN filtering enabled the table is still
> programmed and still enforces port membership.
>
> Fixes: 06cfb2df7eb0 ("net: dsa: don't advertise 'rx-vlan-filter' when not needed")
> Cc: stable@vger.kernel.org
> Signed-off-by: Semih Baskan <strst.gs@gmail.com>
> ---
> I tried setting ds->needs_standalone_vlan_filtering on hardware first. It is
> not sufficient on b53: f089652b6b16 ("net: dsa: b53: do not program vlans
> when vlan filtering is off") makes .port_vlan_add return before the hardware
> write while filtering is off, so the VID still never reaches the table.
> rx-vlan-filter flipped to on and tagged frames were still dropped, 0 of 5.
>
> Relaxing that check instead also works, but only together with the opt-in
> above, since without the feature bit 8021q never calls .port_vlan_add at
> all. Making the port VLAN unaware follows the same switchdev rule that
> commit cites.
>
> I also checked the case where another bridge on the same chip has
> vlan_filtering=1, since b53 sets vlan_filtering_is_global. DSA offloads the
> uppers on the standalone port too, so rx-vlan-filter goes on there and the
> tagged frames keep arriving. This patch cannot execute in that state.
>
>  drivers/net/dsa/b53/b53_common.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
> index 3f5b9592794d..76378afe4993 100644
> --- a/drivers/net/dsa/b53/b53_common.c
> +++ b/drivers/net/dsa/b53/b53_common.c
> @@ -385,6 +385,9 @@ static void b53_enable_vlan(struct b53_device *dev, int port, bool enable,
>  {
>         u8 mgmt, vc0, vc1, vc4 = 0, vc5;
>
> +       if (!enable_filtering && dev->tag_protocol != DSA_TAG_PROTO_NONE)
> +               enable = false;
> +
>         b53_read8(dev, B53_CTRL_PAGE, B53_SWITCH_MODE, &mgmt);
>         b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL0, &vc0);
>         b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL1, &vc1);
> @@ -916,7 +919,7 @@ int b53_configure_vlan(struct dsa_switch *ds)
>                 b53_do_vlan_op(dev, VTA_CMD_CLEAR);
>         }
>
> -       b53_enable_vlan(dev, -1, dev->vlan_enabled, dev->vlan_filtering);
> +       b53_enable_vlan(dev, -1, true, dev->vlan_filtering);
>
>         /* Create an untagged VLAN entry for the default PVID in case
>          * CONFIG_VLAN_8021Q is disabled and there are no calls to

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

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

[Semih Baskan]

On 8/5/26 09:44, Jonas Gorski wrote:
> Unfortunately what this does is break modifying ARL entries with VID
> != 0, which is why I haven't added this.

Thank you for the review, your concerns are justified. I will drop this
patch and let you know if I find a way to address them.

Best regards,
Semih

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

[Vladimir Oltean]

On Wed, Aug 05, 2026 at 09:44:51AM +0200, Jonas Gorski wrote:
> 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.

Is this a hardware limitation, or is it because global state
(dev->vlan_enabled) blinds b53_arl_rw_op()'s attempts to look at FDB
entries of the other type?

static int b53_arl_rw_op(struct b53_device *dev, unsigned int op)
{
	u8 reg;

	if (op > ARLTBL_RW)
		return -EINVAL;

	b53_read8(dev, B53_ARLIO_PAGE, B53_ARLTBL_RW_CTRL, &reg);
	reg |= ARLTBL_START_DONE;
	if (op)
		reg |= ARLTBL_RW;
	else
		reg &= ~ARLTBL_RW;
	if (dev->vlan_enabled)
		reg &= ~ARLTBL_IVL_SVL_SELECT;
	else
		reg |= ARLTBL_IVL_SVL_SELECT;
	b53_write8(dev, B53_ARLIO_PAGE, B53_ARLTBL_RW_CTRL, reg);

	return b53_arl_op_wait(dev);
}

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

[Semih Baskan]

Hi Vladimir,

> Is this a hardware limitation, or is it because global state
> (dev->vlan_enabled) blinds b53_arl_rw_op()'s attempts to look at FDB
> entries of the other type?

I tested that separation on the RT-N18U (BCM53011 rev 5) during the
measurements for the new series. Two builds kept ARLTBL_IVL_SVL_SELECT
at IVL while disabling the table, so the ARL read/write ops were never
switched to SVL:

  - table off, select held at IVL, VC0 learning-mode bits cleared: a
    static entry with VID 100, present in the hardware dump before the
    toggle, is gone from the dump after it
  - table off, select held at IVL, VC0 "individual VLAN learning mode"
    bits (bits 6:5) kept set as well: same result
  - positive control, table on, identical toggle: the entry survives
    and the dump shows it

The observable is the fdb search path (bridge fdb show dev ... self),
which does not go through b53_arl_rw_op() at all: b53_fdb_dump() only
touches the ARL search registers. The same dump shows the entry before
the toggle and shows survival in the table-on control, so it can tell
the difference. With every mode input the driver has held at IVL, and
with the reads happening through a path b53_arl_rw_op() cannot blind,
the entry still does not survive disabling the table. On this chip
that makes it a property of the table being off rather than an
artifact of the select flip. Jonas also noted in the new thread that
ARLTBL_IVL_SVL_SELECT is not implemented on 5301x at all, which fits:
the bit visibly did nothing in these tests.

I cannot rule out that the entries still sit in silicon and are merely
unreachable in every mode the driver can program, but for the driver
and for forwarding they behave as lost either way.

The measurements are summarized in the new series' cover letter:

https://lore.kernel.org/all/20260806073119.387-1-strst.gs@gmail.com/

Best regards,
Semih

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

[Jonas Gorski]

On Thu, Aug 6, 2026 at 12:23 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Wed, Aug 05, 2026 at 09:44:51AM +0200, Jonas Gorski wrote:
> > 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.
>
> Is this a hardware limitation, or is it because global state
> (dev->vlan_enabled) blinds b53_arl_rw_op()'s attempts to look at FDB
> entries of the other type?

This is a hardware limitation.

The hardware hash function to determine the table index for a {
VID,MAC } entry ignores the VID field (or rather treats it as 0) when
filtering / 802.1q mode is disabled. This is done for all ARL
accesses, both destination port lookup on forwarding as well as when
doing ARL table operations.

You can manually write entries with VID != 0 as the VID used for table
index calculation and the VID of the entry are two different register
fields, but the entry will then be written to the wrong index,
preventing them from being matched when looking them up on forwarding
in filtering/802.1q mode.

I verified this by writing entries with VID != 0 with 802.1q mode
disabled, and then looking up the MAC for VID 0 with 802.1q mode
enabled, which then found the entry with the VID != 0, and looking up
the MAC with the entry's VID did not find the correct entry.

>
> static int b53_arl_rw_op(struct b53_device *dev, unsigned int op)
> {
>         u8 reg;
>
>         if (op > ARLTBL_RW)
>                 return -EINVAL;
>
>         b53_read8(dev, B53_ARLIO_PAGE, B53_ARLTBL_RW_CTRL, &reg);
>         reg |= ARLTBL_START_DONE;
>         if (op)
>                 reg |= ARLTBL_RW;
>         else
>                 reg &= ~ARLTBL_RW;
>         if (dev->vlan_enabled)
>                 reg &= ~ARLTBL_IVL_SVL_SELECT;
>         else
>                 reg |= ARLTBL_IVL_SVL_SELECT;

This ARLTBL_IVL_SVL_SELECT bit is only implemented for a small subset
of switches (bcm5302x / bcm58* and bcm53134). Additionally, according
to the register description, this also requires enabling "per port
IVL/SVL" mode, which is not enable by b53. The description of that
also says that the VIDs used in SVL ports must not be used in IVL
ports. No idea what the consequences are if they do.

Best regards,
Jonas

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

[Vladimir Oltean]

On Thu, Aug 06, 2026 at 01:09:03PM +0200, Jonas Gorski wrote:
> > static int b53_arl_rw_op(struct b53_device *dev, unsigned int op)
> > {
> >         u8 reg;
> >
> >         if (op > ARLTBL_RW)
> >                 return -EINVAL;
> >
> >         b53_read8(dev, B53_ARLIO_PAGE, B53_ARLTBL_RW_CTRL, &reg);
> >         reg |= ARLTBL_START_DONE;
> >         if (op)
> >                 reg |= ARLTBL_RW;
> >         else
> >                 reg &= ~ARLTBL_RW;
> >         if (dev->vlan_enabled)
> >                 reg &= ~ARLTBL_IVL_SVL_SELECT;
> >         else
> >                 reg |= ARLTBL_IVL_SVL_SELECT;
> 
> This ARLTBL_IVL_SVL_SELECT bit is only implemented for a small subset
> of switches (bcm5302x / bcm58* and bcm53134). Additionally, according
> to the register description, this also requires enabling "per port
> IVL/SVL" mode, which is not enable by b53. The description of that
> also says that the VIDs used in SVL ports must not be used in IVL
> ports. No idea what the consequences are if they do.

What does enabling per port IVL/SVL mode do?

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

[Jonas Gorski]

On Mon, Aug 10, 2026 at 2:04 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> On Thu, Aug 06, 2026 at 01:09:03PM +0200, Jonas Gorski wrote:
> > > static int b53_arl_rw_op(struct b53_device *dev, unsigned int op)
> > > {
> > >         u8 reg;
> > >
> > >         if (op > ARLTBL_RW)
> > >                 return -EINVAL;
> > >
> > >         b53_read8(dev, B53_ARLIO_PAGE, B53_ARLTBL_RW_CTRL, &reg);
> > >         reg |= ARLTBL_START_DONE;
> > >         if (op)
> > >                 reg |= ARLTBL_RW;
> > >         else
> > >                 reg &= ~ARLTBL_RW;
> > >         if (dev->vlan_enabled)
> > >                 reg &= ~ARLTBL_IVL_SVL_SELECT;
> > >         else
> > >                 reg |= ARLTBL_IVL_SVL_SELECT;
> >
> > This ARLTBL_IVL_SVL_SELECT bit is only implemented for a small subset
> > of switches (bcm5302x / bcm58* and bcm53134). Additionally, according
> > to the register description, this also requires enabling "per port
> > IVL/SVL" mode, which is not enable by b53. The description of that
> > also says that the VIDs used in SVL ports must not be used in IVL
> > ports. No idea what the consequences are if they do.
>
> What does enabling per port IVL/SVL mode do?

I don't have access to a datasheet or a device to test, Florian will
need to answer that completely.

I can only guess from the register descriptions, which imply that
enabling SVL for port makes any ARL lookups SVL based, i.e. VID is
ignored/forced to 0. Presumably this essentially only applies to for
frames received on that port for lookup / learning.

There is a global option for configuring IVL or SVL, but this option
is only valid when VLAN-aware is enabled in the switch. Without it,
learning is always SVL.

I do not know how the per port IVL/SVL actually register works, and
whether you can enable IVL in VLAN-unaware mode (I would guess not).

Note that there is no differentiation in ARL entries themselves
whether they are IVL or SVL entries, only the table index calculation
changes.

Best regards,
Jonas

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

[Florian Fainelli]

On 8/11/26 01:06, Jonas Gorski wrote:
> On Mon, Aug 10, 2026 at 2:04 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>>
>> On Thu, Aug 06, 2026 at 01:09:03PM +0200, Jonas Gorski wrote:
>>>> static int b53_arl_rw_op(struct b53_device *dev, unsigned int op)
>>>> {
>>>>          u8 reg;
>>>>
>>>>          if (op > ARLTBL_RW)
>>>>                  return -EINVAL;
>>>>
>>>>          b53_read8(dev, B53_ARLIO_PAGE, B53_ARLTBL_RW_CTRL, &reg);
>>>>          reg |= ARLTBL_START_DONE;
>>>>          if (op)
>>>>                  reg |= ARLTBL_RW;
>>>>          else
>>>>                  reg &= ~ARLTBL_RW;
>>>>          if (dev->vlan_enabled)
>>>>                  reg &= ~ARLTBL_IVL_SVL_SELECT;
>>>>          else
>>>>                  reg |= ARLTBL_IVL_SVL_SELECT;
>>>
>>> This ARLTBL_IVL_SVL_SELECT bit is only implemented for a small subset
>>> of switches (bcm5302x / bcm58* and bcm53134). Additionally, according
>>> to the register description, this also requires enabling "per port
>>> IVL/SVL" mode, which is not enable by b53. The description of that
>>> also says that the VIDs used in SVL ports must not be used in IVL
>>> ports. No idea what the consequences are if they do.
>>
>> What does enabling per port IVL/SVL mode do?
> 
> I don't have access to a datasheet or a device to test, Florian will
> need to answer that completely.

Not a whole lot of details in the datasheet, but essentially what is 
being provided is:

IVL: a given MAC address can only appear in one VLAN
SVL: a given MAC address can appear on different ports as long as the 
ports are not in the same VLAN.

> 
> I can only guess from the register descriptions, which imply that
> enabling SVL for port makes any ARL lookups SVL based, i.e. VID is
> ignored/forced to 0. Presumably this essentially only applies to for
> frames received on that port for lookup / learning.
> 
> There is a global option for configuring IVL or SVL, but this option
> is only valid when VLAN-aware is enabled in the switch. Without it,
> learning is always SVL.
> 
> I do not know how the per port IVL/SVL actually register works, and
> whether you can enable IVL in VLAN-unaware mode (I would guess not).

IVL/SVL applies to 802.1Q (VLAN enabled) mode, double tagging mode and 
individual double tagging mode, so yes this depends on VLAN being 
enabled globally.

> 
> Note that there is no differentiation in ARL entries themselves
> whether they are IVL or SVL entries, only the table index calculation
> changes.
> 
> Best regards,
> Jonas


-- 
Florian

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

[Vladimir Oltean]

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.

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

[Vladimir Oltean]

On Wed, Aug 12, 2026 at 11:50:47PM +0300, Vladimir Oltean wrote:
> 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

Actually this algorithm is too simplistic as I specified it. In this sequence:

ip link add br0 type bridge vlan_filtering 0 && ip link set swp0 master br0
bridge fdb add swp0 00:01:02:03:04:05 master static
ip link set br0 type bridge vlan_filtering 1
ip link set br0 type bridge vlan_filtering 0 # the 00:01:02:03:04:05 address would be lost here

Furthermore, the ARL is limited in size (1024, 2048 or 4096 entries),
and we could mistakenly end up queuing more than we can commit.

I'm not yet sure what are reasonable amendments that would keep the
complexity in check. Currently the most obvious would be to do a one-time
allocation of dev->num_arl_bins * dev->num_arl_buckets, to always keep
all entries in software, and only the active ones in hardware. But I
need to think about this some more, as I'm aware OpenWrt typically
doesn't operate with huge memory budgets.

I'm not sure that avoiding local copies is possible, because the ARL
entries don't come from a single source - we have bridge FDB, bridge
MDB, ndo_dflt_fdb_add(), dev->uc, dev->mc, dev->dev_addr, sometimes
replicated per VLAN, etc. They all only converge at driver level.

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

[Florian Fainelli]

On 8/12/26 15:06, Vladimir Oltean wrote:
> On Wed, Aug 12, 2026 at 11:50:47PM +0300, Vladimir Oltean wrote:
>> 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
> 
> Actually this algorithm is too simplistic as I specified it. In this sequence:
> 
> ip link add br0 type bridge vlan_filtering 0 && ip link set swp0 master br0
> bridge fdb add swp0 00:01:02:03:04:05 master static
> ip link set br0 type bridge vlan_filtering 1
> ip link set br0 type bridge vlan_filtering 0 # the 00:01:02:03:04:05 address would be lost here
> 
> Furthermore, the ARL is limited in size (1024, 2048 or 4096 entries),
> and we could mistakenly end up queuing more than we can commit.
> 
> I'm not yet sure what are reasonable amendments that would keep the
> complexity in check. Currently the most obvious would be to do a one-time
> allocation of dev->num_arl_bins * dev->num_arl_buckets, to always keep
> all entries in software, and only the active ones in hardware. But I
> need to think about this some more, as I'm aware OpenWrt typically
> doesn't operate with huge memory budgets.
> 
> I'm not sure that avoiding local copies is possible, because the ARL
> entries don't come from a single source - we have bridge FDB, bridge
> MDB, ndo_dflt_fdb_add(), dev->uc, dev->mc, dev->dev_addr, sometimes
> replicated per VLAN, etc. They all only converge at driver level.
> 

Would not we just be better off with enforcing vlan_filtering=1 for any 
bridge that is created? Unlike Marvell switches, the Roboswitch has no 
notion of egress as tag unmodified unfortunately.
-- 
Florian