[PATCH net v3 0/2] net: dsa: b53: fix 8021q uppers on standalone ports

[PATCH net v3 0/2] net: dsa: b53: fix 8021q uppers on standalone ports

[Semih Baskan]

Since v5.15, a standalone port on a bcm5301x b53 switch cannot receive
its own tagged traffic: the switch VID lookup is always active, an 8021q
upper's VID never reaches the VLAN table, and a tagged frame with a
missing VID is forwarded only toward the IMP0 management port, which the
in-tree bcm5301x topology leaves disabled, so it never reaches the CPU.
The common victim is a VLAN-tagged PPPoE WAN, where the PADI goes out
and the tagged PADO never reaches the CPU.

My first attempt disabled the VLAN table while not filtering:

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

Jonas pointed out that this moves the ARL to shared VLAN learning and
desynchronizes the hardware table from the bridge fdb, and I withdrew
it. I then measured the alternatives on an RT-N18U (BCM53011 rev 5),
with the outbound direction of the same link as a positive control on
every run:

  - With the table enabled, no ingress VID check setting delivers the
    frame: VC4_NO_ING_VID_CHK, VC4_ING_VID_VIO_FWD and
    VC4_ING_VID_VIO_TO_IMP all give 0, and the miss control bit
    VC5_DROP_VTABLE_MISS already sits in its non-drop state, whose only
    delivery target is the disabled IMP0. The frame does not die at
    ingress admission, it dies on the miss path behind it.
  - With the table disabled, a static fdb entry with VID 100 is lost
    from the hardware ARL no matter how the driver drives the ARL
    registers: keeping ARLTBL_IVL_SVL_SELECT at IVL does not preserve
    it, and neither does additionally keeping the VID learning bits in
    VLAN_CTRL0 set.
  - The VID to PVID rewrite bit (CHANGE_1Q_VID) does deliver such a
    frame, but only by rewriting the VID to the PVID, which destroys the
    VID the upper is keyed on.

So on this hardware, delivering the frame and keeping VID-keyed ARL
entries are mutually exclusive unless the VID is in the table. This
series therefore programs the table, narrowed to what is actually
needed: a standalone port only needs the VIDs its 8021q uppers use,
which is one table write per upper instead of entries for all 4096
VIDs.

I looked for a fix inside b53 first. The one existing way to have the
upper VIDs delivered to the driver, ds->needs_standalone_vlan_filtering,
does not work here. It was measured insufficient, because f089652b6b16
makes .port_vlan_add skip the hardware write while not filtering, and
its other effect is one b53 cannot take: with vlan_filtering_is_global,
the forced vlan_filtering=1 in dsa_port_reset_vlan_filtering() would
flip the whole switch into VLAN filtering when any port leaves a
VLAN-unaware bridge. hellcreek relies on exactly those semantics, so
patch 1 adds a narrower opt-in that only delivers the VIDs and leaves
vlan_filtering alone, and patch 2 uses it in b53 and programs entries
that carry standalone members, masked so bridge VLANs stay without
effect while not filtering.

Tested on the RT-N18U: the standalone upper receives 7 of 7 probe frames
with vlan_filtering staying 0, the static fdb entry with a VID now
survives a vlan_filtering toggle since the table enable and the ARL mode
are never touched, uppers keep working across bridge join and leave and
across a vlan_filtering toggle including on ports that were bridged
while the toggle happened, deleting an upper or bridging its port
verifiably stops delivery of that VID to the CPU, and the PPPoE session
establishes. 802.1ad uppers keep working as software VLANs, since this
switch does not parse 0x88a8, and stacked QinQ over an offloaded upper
works too.

Changes in v3:
 - patch 2: BCM5325 and BCM5365 are left out of the opt-in, which now
   gets set after chip detection. Both forward a VLAN table miss, so
   their standalone uppers already work, and their tables hold only 16
   and 256 entries, so v2 made b53_vlan_prepare() refuse an upper whose
   VID lies beyond the table. The message no longer claims such uppers
   fail loudly.
 - patch 1: unchanged.

Changes in v2:
 - patch 1's commit message rewritten after Vladimir Oltean's review.
 - the delivery failure is scoped to bcm5301x in both messages; Jonas
   Gorski observed that other family members still deliver unknown
   VIDs, and the programmed entries are correct there as well.
 - the cover's description of the miss path corrected per the v1
   thread register discussion, and the measured alternatives extended
   with the CHANGE_1Q_VID result.
 - patch 1: the conduit change path no longer skips ports that sit
   under a bridge; with the permanent feature bit their uppers are
   offloaded too, so their CPU port VLANs must move with the conduit.
   Not reachable on b53, which has no .port_change_conduit.
 - patch 2: code unchanged.

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

Semih Baskan (2):
  net: dsa: let drivers offload 8021q uppers on standalone ports
  net: dsa: b53: offload 8021q uppers on standalone ports

 drivers/net/dsa/b53/b53_common.c | 119 ++++++++++++++++++++++++++-----
 include/net/dsa.h                |   3 +
 net/dsa/port.c                   |  22 ++++--
 net/dsa/user.c                   |   4 +-
 4 files changed, 122 insertions(+), 26 deletions(-)

-- 
2.53.0.windows.1

[PATCH net v3 1/2] net: dsa: let drivers offload 8021q uppers on standalone ports

[Semih Baskan]

Before v5.15, DSA delivered the VIDs of 8021q uppers to switch
drivers unconditionally: user ports advertised
NETIF_F_HW_VLAN_CTAG_FILTER, the 8021q layer reported upper VIDs to
.ndo_vlan_rx_add_vid, and .port_vlan_add programmed them whether or
not a bridge had enabled VLAN filtering. Commit 06cfb2df7eb0 ("net:
dsa: don't advertise 'rx-vlan-filter' when not needed") stopped the
delivery for standalone ports and commit f089652b6b16 ("net: dsa: b53:
do not program vlans when vlan filtering is off") stopped the
programming, on the model that a standalone port is VLAN-unaware and
any 8021q upper is a software VLAN.

That model does not fit hardware whose VID lookup cannot be turned off.
b53 keeps its lookup enabled at all times, because disabling it moves
the ARL to shared VLAN learning: the hash that selects the ARL slot then
treats every VID as 0, entries keyed by a real VID become unreachable,
and the hardware table drifts away from the bridge fdb. With the lookup
active, a tagged frame whose VID is absent from the table is discarded
before it reaches the CPU, measured on bcm5301x. Such a port is never
VLAN-unaware, whatever the bridge asked for. Commit 06cfb2df7eb0 ("net:
dsa: don't advertise 'rx-vlan-filter' when not needed") lists the
reasons a driver may keep it on, and this is its first case, standalone
ports that would otherwise drop VLAN-tagged traffic, except that here
the VLAN awareness is held on by the silicon itself rather than by a
VLAN-aware bridge elsewhere on the switch.

The existing opt-in, ds->needs_standalone_vlan_filtering, is not a
fit. It exists for hellcreek, whose traffic separation depends on
per-port VLANs, so standalone operation there needs the
vlan_filtering state itself forced on:
dsa_port_reset_vlan_filtering() forces vlan_filtering=1 when a port
leaves a VLAN-unaware bridge, and with vlan_filtering_is_global that
lands the whole switch in the state hellcreek wants. On b53 the same
flip is a user-visible mode change for every port on the switch:
bridge VLANs that were committed while inactive become enforced, and
the unknown-VID ingress drop modes turn on chip-wide.
b53 needs the VIDs, not the state.

Add ds->needs_standalone_vlan_offload for that narrower need. It
advertises NETIF_F_HW_VLAN_CTAG_FILTER on user ports permanently, so
upper VIDs reach .port_vlan_add again, and it leaves the
vlan_filtering state alone. This restores the pre-v5.15 delivery
pipeline for drivers that opt in and changes nothing for drivers
that do not.

A permanent feature bit also means dsa_user_manage_vlan_filtering()
must not run on vlan_filtering toggles of such a switch. The
ds->ops->port_vlan_filtering call is unchanged and the driver still
sees every toggle; what is skipped only toggles the feature bit and
replays or clears the VID list, and both halves are wrong when the
bit never goes away. The replay re-adds VIDs that were never cleared,
so vlan_vid_add() refcounts every upper VID twice. The clear strips
the feature bit and the VIDs from a port that happens to be bridged
at toggle time, and its uppers then stay dead even after it leaves
the bridge, because nothing re-offloads them once the feature bit is
gone. Both effects were measured on bcm5301x hardware. The conduit
change path keeps its explicit teardown and restore of the 8021q
upper VLANs, and now runs it for every port of such a switch,
bridged or not, because with the permanent feature bit every port
with uppers has VLANs on the CPU port.

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>
---
 include/net/dsa.h |  3 +++
 net/dsa/port.c    | 22 +++++++++++++++-------
 net/dsa/user.c    |  4 +++-
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 7507d632e7c6..67a01fc5f81e 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -405,6 +405,9 @@ struct dsa_switch {
 	/* Keep VLAN filtering enabled on ports not offloading any upper */
 	u32			needs_standalone_vlan_filtering:1;
 
+	/* Offload 8021q uppers of standalone ports even when not filtering */
+	u32			needs_standalone_vlan_offload:1;
+
 	/* Pass .port_vlan_add and .port_vlan_del to drivers even for bridges
 	 * that have vlan_filtering=0. All drivers should ideally set this (and
 	 * then the option would get removed), but it is unknown whether this
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 1f5536c0dffc..e61abc7c74f7 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -831,6 +831,9 @@ int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering,
 			if (!user)
 				continue;
 
+			if (ds->needs_standalone_vlan_offload)
+				continue;
+
 			err = dsa_user_manage_vlan_filtering(user,
 							     vlan_filtering);
 			if (err)
@@ -839,10 +842,12 @@ int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering,
 	} else {
 		dp->vlan_filtering = vlan_filtering;
 
-		err = dsa_user_manage_vlan_filtering(dp->user,
-						     vlan_filtering);
-		if (err)
-			goto restore;
+		if (!ds->needs_standalone_vlan_offload) {
+			err = dsa_user_manage_vlan_filtering(dp->user,
+							     vlan_filtering);
+			if (err)
+				goto restore;
+		}
 	}
 
 	return 0;
@@ -1445,10 +1450,13 @@ int dsa_port_change_conduit(struct dsa_port *dp, struct net_device *conduit,
 
 	/* The port might still be VLAN filtering even if it's no longer
 	 * under a bridge, either due to ds->vlan_filtering_is_global or
-	 * ds->needs_standalone_vlan_filtering. In turn this means VLANs
-	 * on the CPU port.
+	 * ds->needs_standalone_vlan_filtering, and every port of a
+	 * ds->needs_standalone_vlan_offload switch keeps its 8021q upper
+	 * VLANs whether bridged or not. In turn this means VLANs on the
+	 * CPU port.
 	 */
-	vlan_filtering = dsa_port_is_vlan_filtering(dp);
+	vlan_filtering = dsa_port_is_vlan_filtering(dp) ||
+			 ds->needs_standalone_vlan_offload;
 	if (vlan_filtering) {
 		err = dsa_user_manage_vlan_filtering(dev, false);
 		if (err) {
diff --git a/net/dsa/user.c b/net/dsa/user.c
index 041f9060c8ef..fda6ba4fdd13 100644
--- a/net/dsa/user.c
+++ b/net/dsa/user.c
@@ -1946,6 +1946,7 @@ static int dsa_user_clear_vlan(struct net_device *vdev, int vid, void *arg)
  *
  * - If standalone (this includes software bridge, software LAG):
  *     - if ds->needs_standalone_vlan_filtering = true, OR if
+ *       ds->needs_standalone_vlan_offload = true, OR if
  *       (ds->vlan_filtering_is_global = true AND there are bridges spanning
  *       this switch chip which have vlan_filtering=1)
  *         - the 8021q upper VLANs
@@ -2717,7 +2718,8 @@ void dsa_user_setup_tagger(struct net_device *user)
 	user->hw_features |= NETIF_F_HW_TC;
 	if (user->needed_tailroom)
 		user->features &= ~(NETIF_F_SG | NETIF_F_FRAGLIST);
-	if (ds->needs_standalone_vlan_filtering)
+	if (ds->needs_standalone_vlan_filtering ||
+	    ds->needs_standalone_vlan_offload)
 		user->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
 
 	user->lltx = true;
-- 
2.53.0.windows.1

[PATCH net v3 2/2] net: dsa: b53: offload 8021q uppers on standalone ports

[Semih Baskan]

b53 keeps the hardware VID lookup enabled at all times:
b53_switch_alloc() sets dev->vlan_enabled and nothing ever clears it. On
bcm5301x switches, a tagged frame whose VID is absent from the VLAN
table is forwarded only toward the IMP0 management port, which the
in-tree topology leaves disabled, so it never reaches the CPU. Jonas
Gorski reports that other family members still deliver such frames,
older BCM5325/5365 by forwarding them and BCM63268/BCM53115 to the CPU
only, and the entries this patch programs are correct on BCM63268 and
BCM53115 as well. Disabling the lookup is not an option either, because
that moves the ARL to shared VLAN learning, where ARL operations force
VID 0 and the hardware table drifts away from the bridge fdb.

Commit 06cfb2df7eb0 ("net: dsa: don't advertise 'rx-vlan-filter' when
not needed") stopped advertising NETIF_F_HW_VLAN_CTAG_FILTER on ports
that do not offload a VLAN-aware bridge, so creating an 8021q upper on
a standalone port no longer reaches .ndo_vlan_rx_add_vid and the VID
is never offloaded. Commit f089652b6b16 ("net: dsa: b53: do not
program vlans when vlan filtering is off") then made .port_vlan_add
skip the hardware write while dev->vlan_filtering is false, which it
is for a standalone port. Together they leave standalone ports unable
to receive their own tagged traffic.

This breaks a common configuration, a VLAN-tagged WAN for a PPPoE ISP.
The PADI leaves the port correctly tagged, the concentrator answers,
and the switch discards the tagged PADO, so the session never
establishes. The breakage reached users when OpenWrt 23.05 shipped
v5.15 and is still reproducible.

Take the new needs_standalone_vlan_offload opt-in so DSA reports upper
VIDs again, and program VLAN entries that carry a standalone port even
while not filtering. Only the standalone members and the CPU port are
written to such an entry. A VID used by both an 8021q upper and a
bridge VLAN therefore does not gain the bridged ports as members, so
bridge VLANs keep having no effect while filtering is off, which is
what Documentation/networking/switchdev.rst requires and what that
commit implements. The PVID register writes stay gated on
vlan_filtering for the same reason.

BCM5325 and BCM5365 stay out of the opt-in, which is why the flag is
set after chip detection rather than in b53_switch_alloc(). Both
forward a table miss, so a standalone port there already receives its
uppers' traffic with no entry. Their tables also hold only 16 and 256
VLANs, and with the feature bit back on b53_vlan_prepare() would refuse
any upper whose VID lies beyond the table, an interface that works
today.

b53_configure_vlan() used to restore entries only while filtering, so
restore the standalone ones there as well, otherwise the next
b53_apply_config() wipes them. Bridge join and leave rewrite the
entries of the moved port, because its standalone state is part of the
masking decision: joining removes the port from its uppers' entries,
and leaving adds it back, including uppers that were created while the
port was still bridged. When the last standalone member leaves a VID,
the entry is written back empty, so deleting an upper or bridging its
port returns the hardware to the state it had before the upper
existed.

A tagged upper on BCM7278 port 7 now fails at creation:
b53_vlan_prepare() rejects tagged VLANs on that port, which cannot
receive tagged frames. Previously the ndo was never called, so the
upper was silently created broken.

Measured on an Asus RT-N18U (BCM53011 rev 5) against a peer device. A
probe over an 8021q upper on the standalone WAN port received 0 frames
before and 7 of 7 after, with the outbound direction as a positive
control and vlan_filtering staying 0 throughout. A static fdb entry
with VID 100 survived a vlan_filtering 1->0 toggle in hardware, since
dev->vlan_enabled is never touched and the ARL keeps using independent
VLAN learning. The PPPoE session establishes.

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>
---
 drivers/net/dsa/b53/b53_common.c | 119 ++++++++++++++++++++++++++-----
 1 file changed, 101 insertions(+), 18 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 0880310c9ce3..b57c0bdacb27 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -898,10 +898,52 @@ static bool b53_vlan_port_may_join_untagged(struct dsa_switch *ds, int port)
 	return dp->bridge == NULL;
 }
 
+static bool b53_vlan_hw_entry(struct dsa_switch *ds, const struct b53_vlan *vl,
+			      struct b53_vlan *hw)
+{
+	struct b53_device *dev = ds->priv;
+	bool standalone = false;
+	struct dsa_port *dp;
+	unsigned int port;
+
+	*hw = *vl;
+
+	if (dev->vlan_filtering)
+		return true;
+
+	hw->members = 0;
+	hw->untag = 0;
+
+	b53_for_each_port(dev, port) {
+		if (!(vl->members & BIT(port)))
+			continue;
+
+		dp = dsa_to_port(ds, port);
+
+		if (!dsa_port_is_cpu(dp)) {
+			if (dp->bridge)
+				continue;
+
+			standalone = true;
+		}
+
+		hw->members |= BIT(port);
+		hw->untag |= vl->untag & BIT(port);
+	}
+
+	if (!standalone) {
+		hw->members = 0;
+		hw->untag = 0;
+	}
+
+	return standalone;
+}
+
 int b53_configure_vlan(struct dsa_switch *ds)
 {
 	struct b53_device *dev = ds->priv;
 	struct b53_vlan vl = { 0 };
+	struct b53_vlan hw;
 	struct b53_vlan *v;
 	int i, def_vid;
 	u16 vid;
@@ -937,20 +979,23 @@ int b53_configure_vlan(struct dsa_switch *ds)
 	}
 	b53_set_vlan_entry(dev, def_vid, &vl);
 
-	if (dev->vlan_filtering) {
-		/* Upon initial call we have not set-up any VLANs, but upon
-		 * system resume, we need to restore all VLAN entries.
-		 */
-		for (vid = def_vid + 1; vid < dev->num_vlans; vid++) {
-			v = &dev->vlans[vid];
+	/* Upon initial call we have not set-up any VLANs, but upon
+	 * system resume, we need to restore all VLAN entries.
+	 */
+	for (vid = def_vid + 1; vid < dev->num_vlans; vid++) {
+		v = &dev->vlans[vid];
 
-			if (!v->members)
-				continue;
+		if (!v->members)
+			continue;
 
-			b53_set_vlan_entry(dev, vid, v);
-			b53_fast_age_vlan(dev, vid);
-		}
+		if (!b53_vlan_hw_entry(ds, v, &hw))
+			continue;
+
+		b53_set_vlan_entry(dev, vid, &hw);
+		b53_fast_age_vlan(dev, vid);
+	}
 
+	if (dev->vlan_filtering) {
 		b53_for_each_port(dev, i) {
 			if (!dsa_is_cpu_port(ds, i))
 				b53_write16(dev, B53_VLAN_PAGE,
@@ -1720,6 +1765,7 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	struct b53_device *dev = ds->priv;
 	bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
 	bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
+	struct b53_vlan hw;
 	struct b53_vlan *vl;
 	u16 old_pvid, new_pvid;
 	int err;
@@ -1751,13 +1797,14 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	else
 		vl->untag &= ~BIT(port);
 
-	if (!dev->vlan_filtering)
+	if (!b53_vlan_hw_entry(ds, vl, &hw))
 		return 0;
 
-	b53_set_vlan_entry(dev, vlan->vid, vl);
+	b53_set_vlan_entry(dev, vlan->vid, &hw);
 	b53_fast_age_vlan(dev, vlan->vid);
 
-	if (!dsa_is_cpu_port(ds, port) && new_pvid != old_pvid) {
+	if (dev->vlan_filtering &&
+	    !dsa_is_cpu_port(ds, port) && new_pvid != old_pvid) {
 		b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port),
 			    new_pvid);
 		b53_fast_age_vlan(dev, old_pvid);
@@ -1772,7 +1819,9 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
 {
 	struct b53_device *dev = ds->priv;
 	bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
+	struct b53_vlan hw;
 	struct b53_vlan *vl;
+	bool needs_hw;
 	u16 pvid;
 
 	if (vlan->vid == 0)
@@ -1782,6 +1831,8 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
 
 	vl = &dev->vlans[vlan->vid];
 
+	needs_hw = b53_vlan_hw_entry(ds, vl, &hw);
+
 	vl->members &= ~BIT(port);
 
 	if (pvid == vlan->vid)
@@ -1791,14 +1842,18 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
 	if (untagged && !b53_vlan_port_needs_forced_tagged(ds, port))
 		vl->untag &= ~(BIT(port));
 
-	if (!dev->vlan_filtering)
+	if (!needs_hw)
 		return 0;
 
-	b53_set_vlan_entry(dev, vlan->vid, vl);
+	b53_vlan_hw_entry(ds, vl, &hw);
+	b53_set_vlan_entry(dev, vlan->vid, &hw);
 	b53_fast_age_vlan(dev, vlan->vid);
 
-	b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), pvid);
-	b53_fast_age_vlan(dev, pvid);
+	if (dev->vlan_filtering) {
+		b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port),
+			    pvid);
+		b53_fast_age_vlan(dev, pvid);
+	}
 
 	return 0;
 }
@@ -2261,6 +2316,28 @@ int b53_mdb_del(struct dsa_switch *ds, int port,
 }
 EXPORT_SYMBOL(b53_mdb_del);
 
+static void b53_standalone_vlan_resync(struct dsa_switch *ds, int port)
+{
+	struct b53_device *dev = ds->priv;
+	struct b53_vlan hw;
+	struct b53_vlan *vl;
+	u16 vid;
+
+	if (dev->vlan_filtering)
+		return;
+
+	for (vid = b53_default_pvid(dev) + 1; vid < dev->num_vlans; vid++) {
+		vl = &dev->vlans[vid];
+
+		if (!(vl->members & BIT(port)))
+			continue;
+
+		b53_vlan_hw_entry(ds, vl, &hw);
+		b53_set_vlan_entry(dev, vid, &hw);
+		b53_fast_age_vlan(dev, vid);
+	}
+}
+
 int b53_br_join(struct dsa_switch *ds, int port, struct dsa_bridge bridge,
 		bool *tx_fwd_offload, struct netlink_ext_ack *extack)
 {
@@ -2324,6 +2401,8 @@ int b53_br_join(struct dsa_switch *ds, int port, struct dsa_bridge bridge,
 	b53_write16(dev, B53_PVLAN_PAGE, B53_PVLAN_PORT_MASK(port), pvlan);
 	dev->ports[port].vlan_ctl_mask = pvlan;
 
+	b53_standalone_vlan_resync(ds, port);
+
 	return 0;
 }
 EXPORT_SYMBOL(b53_br_join);
@@ -2376,6 +2455,8 @@ void b53_br_leave(struct dsa_switch *ds, int port, struct dsa_bridge bridge)
 		vl->members |= BIT(port);
 		b53_set_vlan_entry(dev, pvid, vl);
 	}
+
+	b53_standalone_vlan_resync(ds, port);
 }
 EXPORT_SYMBOL(b53_br_leave);
 
@@ -3172,6 +3253,8 @@ static int b53_switch_init(struct b53_device *dev)
 	if (!dev->vlans)
 		return -ENOMEM;
 
+	dev->ds->needs_standalone_vlan_offload = !is5325(dev) && !is5365(dev);
+
 	dev->reset_gpio = b53_switch_get_reset_gpio(dev);
 
 	if (PTR_ERR(dev->reset_gpio) == -EPROBE_DEFER)
-- 
2.53.0.windows.1

Re: [PATCH net v3 0/2] net: dsa: b53: fix 8021q uppers on standalone ports

[Jonas Gorski]

Hi,

On Mon, Aug 31, 2026 at 10:52 AM Semih Baskan <strst.gs@gmail.com> wrote:
>
> Since v5.15, a standalone port on a bcm5301x b53 switch cannot receive
> its own tagged traffic: the switch VID lookup is always active, an 8021q
> upper's VID never reaches the VLAN table, and a tagged frame with a
> missing VID is forwarded only toward the IMP0 management port, which the
> in-tree bcm5301x topology leaves disabled, so it never reaches the CPU.
> The common victim is a VLAN-tagged PPPoE WAN, where the PADI goes out
> and the tagged PADO never reaches the CPU.

I really don't agree with the framing here. The subject essentially
claims that uppers don't work in general, but that is not true at all.
They don't work for devices with a *broken* device tree configuration.

So this is a work-around for broken configuration.

Also this is an incomplete fix, because it still won't work 100%, and
there is no way to fix this from within the driver, the device tree
needs to be fixed. E.g. with the (assumed) disabled EAP mode on
stand-alone ports, you will have the issue that the switch will drop
any frames with destination MACs that match a learned entry on a
bridged port.

I really think we should just fix up the in-tree device trees and then
complain loudly about the broken configuration on probe in case there
are out of tree device trees with the broken configuration. I mean it
was broken since v5.15 and wasn't noticed until recently, so it
doesn't seem affect many users.

Best regards,
Jonas

Re: [PATCH net v3 0/2] net: dsa: b53: fix 8021q uppers on standalone ports

[Semih Baskan]

Hi Jonas,

On Mon, Aug 31, 2026 at 12:34 PM Jonas Gorski <jonas.gorski@gmail.com> wrote:
> I really think we should just fix up the in-tree device trees and then
> complain loudly about the broken configuration on probe in case there
> are out of tree device trees with the broken configuration.

I agree, fixing this up in the device tree is the more robust way.
In the meantime OpenWrt can carry these patches as a band aid for
the affected boards.

Best regards,
Semih

Re: [PATCH net v3 1/2] net: dsa: let drivers offload 8021q uppers on standalone ports

[Vladimir Oltean]

On Mon, Aug 31, 2026 at 11:52:16AM +0300, Semih Baskan wrote:
> Before v5.15, DSA delivered the VIDs of 8021q uppers to switch
> drivers unconditionally: user ports advertised
> NETIF_F_HW_VLAN_CTAG_FILTER, the 8021q layer reported upper VIDs to
> .ndo_vlan_rx_add_vid, and .port_vlan_add programmed them whether or
> not a bridge had enabled VLAN filtering. Commit 06cfb2df7eb0 ("net:
> dsa: don't advertise 'rx-vlan-filter' when not needed") stopped the
> delivery for standalone ports and commit f089652b6b16 ("net: dsa: b53:
> do not program vlans when vlan filtering is off") stopped the
> programming, on the model that a standalone port is VLAN-unaware and
> any 8021q upper is a software VLAN.
> 
> That model does not fit hardware whose VID lookup cannot be turned off.
> b53 keeps its lookup enabled at all times, because disabling it moves
> the ARL to shared VLAN learning: the hash that selects the ARL slot then
> treats every VID as 0, entries keyed by a real VID become unreachable,
> and the hardware table drifts away from the bridge fdb. With the lookup
> active, a tagged frame whose VID is absent from the table is discarded
> before it reaches the CPU, measured on bcm5301x. Such a port is never
> VLAN-unaware, whatever the bridge asked for. Commit 06cfb2df7eb0 ("net:
> dsa: don't advertise 'rx-vlan-filter' when not needed") lists the
> reasons a driver may keep it on, and this is its first case, standalone
> ports that would otherwise drop VLAN-tagged traffic, except that here
> the VLAN awareness is held on by the silicon itself rather than by a
> VLAN-aware bridge elsewhere on the switch.
> 
> The existing opt-in, ds->needs_standalone_vlan_filtering, is not a
> fit. It exists for hellcreek, whose traffic separation depends on
> per-port VLANs, so standalone operation there needs the
> vlan_filtering state itself forced on:
> dsa_port_reset_vlan_filtering() forces vlan_filtering=1 when a port
> leaves a VLAN-unaware bridge, and with vlan_filtering_is_global that
> lands the whole switch in the state hellcreek wants. On b53 the same
> flip is a user-visible mode change for every port on the switch:
> bridge VLANs that were committed while inactive become enforced, and
> the unknown-VID ingress drop modes turn on chip-wide.
> b53 needs the VIDs, not the state.
> 
> Add ds->needs_standalone_vlan_offload for that narrower need. It
> advertises NETIF_F_HW_VLAN_CTAG_FILTER on user ports permanently, so
> upper VIDs reach .port_vlan_add again, and it leaves the
> vlan_filtering state alone. This restores the pre-v5.15 delivery
> pipeline for drivers that opt in and changes nothing for drivers
> that do not.
> 
> A permanent feature bit also means dsa_user_manage_vlan_filtering()
> must not run on vlan_filtering toggles of such a switch. The
> ds->ops->port_vlan_filtering call is unchanged and the driver still
> sees every toggle; what is skipped only toggles the feature bit and
> replays or clears the VID list, and both halves are wrong when the
> bit never goes away. The replay re-adds VIDs that were never cleared,
> so vlan_vid_add() refcounts every upper VID twice. The clear strips
> the feature bit and the VIDs from a port that happens to be bridged
> at toggle time, and its uppers then stay dead even after it leaves
> the bridge, because nothing re-offloads them once the feature bit is
> gone. Both effects were measured on bcm5301x hardware. The conduit
> change path keeps its explicit teardown and restore of the 8021q
> upper VLANs, and now runs it for every port of such a switch,
> bridged or not, because with the permanent feature bit every port
> with uppers has VLANs on the CPU port.
> 
> 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'm sorry I wasn't clear enough the first time when this patch was
proposed.

Nacked-by: Vladimir Oltean <vladimir.oltean@nxp.com>

If you cannot get VLAN-unaware mode to work on this hardware (though
that would still be preferable), then the only acceptable DSA core
change is to always require NETIF_F_HW_VLAN_CTAG_FILTER on user ports
(what this patch does), *as well as* refuse offloading VLAN-unaware
bridges. Otherwise it is just split-brain logic, where the core
limitation leads to restrictions being applied inconsistently.

Sorry, but you can't talk away the need to also handle VLAN-unaware
bridging when you touch the DSA core.

Re: [PATCH net v3 0/2] net: dsa: b53: fix 8021q uppers on standalone ports

[Florian Fainelli]

On 8/31/2026 3:17 AM, Semih Baskan wrote:
> Hi Jonas,
> 
> On Mon, Aug 31, 2026 at 12:34 PM Jonas Gorski <jonas.gorski@gmail.com> wrote:
>> I really think we should just fix up the in-tree device trees and then
>> complain loudly about the broken configuration on probe in case there
>> are out of tree device trees with the broken configuration.
> 
> I agree, fixing this up in the device tree is the more robust way.
> In the meantime OpenWrt can carry these patches as a band aid for
> the affected boards.

But you control exact how the DTS gets distributed in OpenWrt, why not 
just fix all of the DTSes there and have the users confirm that using 
port 8 as the IMP works?

Don't get me wrong, I am very appreciative that you spent a decent 
amount of time trying to come up with some sort of solution.

Thanks
-- 
Florian

Re: [PATCH net v3 0/2] net: dsa: b53: fix 8021q uppers on standalone ports

[Semih Baskan]

Hi Florian,

On Tue, Sep 1, 2026 at 3:24 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> But you control exact how the DTS gets distributed in OpenWrt, why not
> just fix all of the DTSes there and have the users confirm that using
> port 8 as the IMP works?
>
> Don't get me wrong, I am very appreciative that you spent a decent
> amount of time trying to come up with some sort of solution.

Thank you. Yes, that is what I am planning to do. Port 8 as the IMP
is already confirmed on my board, tagged RX and PPPoE come back with
no driver changes. Next week I will start with my own board in
OpenWrt and hope owners of the other bcm53xx devices can confirm
theirs.

Best regards,
Semih