[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