[PATCH net 00/11] net: dsa: b53: accumulated fixes

[PATCH net 00/11] net: dsa: b53: accumulated fixes

[Jonas Gorski]

This patchset aims at fixing most issues observed while running the
vlan_unaware_bridge, vlan_aware_bridge and local_termination selftests.

Most tests succeed with these patches on BCM53115, connected to a
BCM6368.

It took me a while to figure out that a lot of tests will fail if all
ports have the same MAC address, as the switches drop any frames with
DA == SA. Luckily BCM63XX boards often have enough MACs allocated for
all ports, so I just needed to assign them.

The still failing tests are:

FDB learning, both vlan aware aware and unaware:

This is expected, as b53 currently does not implement changing the
ageing time, and both the bridge code and DSA ignore that, so the
learned entries don't age out as expected.

ping and ping6 in vlan unaware:

These fail because of the now fixed learning, the switch trying to
forward packet ingressing on one of the standalone ports to the learned
port of the mac address when the packets ingressed on the bridged port.

The port VLAN masks only prevent forwarding to other ports, but the ARL
lookup will still happen, and the packet gets dropped because the port
isn't allowed to forward there.

I have a fix/workaround for that, but as it is a bit more controversial
and makes use of an unrelated feature, I decided to hold off from that
and post it later.

This wasn't noticed so far, because learning was never working in VLAN
unaware mode, so the traffic was always broadcast (which sidesteps the
issue).

Finally some of the multicast tests from local_termination fail, where
the reception worked except it shouldn't. This doesn't seem to me as a
super serious issue, so I didn't attempt to debug/fix these yet.

I'm not super confident I didn't break sf2 along the way, but I did
compile test and tried to find ways it cause issues (I failed to find
any). I hope Florian will tell me.

Jonas Gorski (11):
  net: dsa: b53: allow leaky reserved multicast
  net: dsa: b53: keep CPU port always tagged again
  net: dsa: b53: fix clearing PVID of a port
  net: dsa: b53: fix flushing old pvid VLAN on pvid change
  net: dsa: b53: fix VLAN ID for untagged vlan on bridge leave
  net: dsa: b53: always rejoin default untagged VLAN on bridge leave
  net: dsa: b53: do not allow to configure VLAN 0
  net: dsa: b53: do not program vlans when vlan filtering is off
  net: dsa: b53: fix toggling vlan_filtering
  net: dsa: b53: fix learning on VLAN unaware bridges
  net: dsa: b53: do not set learning and unicast/multicast on up

 drivers/net/dsa/b53/b53_common.c | 207 ++++++++++++++++++++++---------
 drivers/net/dsa/b53/b53_priv.h   |   3 +
 drivers/net/dsa/bcm_sf2.c        |   1 +
 3 files changed, 154 insertions(+), 57 deletions(-)

-- 
2.43.0

[PATCH net 01/11] net: dsa: b53: allow leaky reserved multicast

[Jonas Gorski]

Allow reserved multicast to ignore VLAN membership so STP and other
management protocols work without a PVID VLAN configured when using a
vlan aware bridge.

Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index e5ba71897906..62866165ad03 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -373,9 +373,11 @@ static void b53_enable_vlan(struct b53_device *dev, int port, bool enable,
 		b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL5, &vc5);
 	}
 
+	vc1 &= ~VC1_RX_MCST_FWD_EN;
+
 	if (enable) {
 		vc0 |= VC0_VLAN_EN | VC0_VID_CHK_EN | VC0_VID_HASH_VID;
-		vc1 |= VC1_RX_MCST_UNTAG_EN | VC1_RX_MCST_FWD_EN;
+		vc1 |= VC1_RX_MCST_UNTAG_EN;
 		vc4 &= ~VC4_ING_VID_CHECK_MASK;
 		if (enable_filtering) {
 			vc4 |= VC4_ING_VID_VIO_DROP << VC4_ING_VID_CHECK_S;
@@ -393,7 +395,7 @@ static void b53_enable_vlan(struct b53_device *dev, int port, bool enable,
 
 	} else {
 		vc0 &= ~(VC0_VLAN_EN | VC0_VID_CHK_EN | VC0_VID_HASH_VID);
-		vc1 &= ~(VC1_RX_MCST_UNTAG_EN | VC1_RX_MCST_FWD_EN);
+		vc1 &= ~VC1_RX_MCST_UNTAG_EN;
 		vc4 &= ~VC4_ING_VID_CHECK_MASK;
 		vc5 &= ~VC5_DROP_VTABLE_MISS;
 
-- 
2.43.0

[PATCH net 02/11] net: dsa: b53: keep CPU port always tagged again

[Jonas Gorski]

The Broadcom management header does not carry the original VLAN tag
state information, just the ingress port, so for untagged frames we do
not know from which VLAN they originated.

Therefore keep the CPU port always tagged except for VLAN 0.

Fixes the following setup:

$ ip link add br0 type bridge vlan_filtering 1
$ ip link set sw1p1 master br0
$ bridge vlan add dev br0 pvid untagged self
$ ip link add sw1p2.10 link sw1p2 type vlan id 10

Where VID 10 would stay untagged on the CPU port.

Fixes: 2c32a3d3c233 ("net: dsa: b53: Do not force CPU to be always tagged")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 62866165ad03..9d4fb54b4ced 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1135,6 +1135,11 @@ static int b53_setup(struct dsa_switch *ds)
 	 */
 	ds->untag_bridge_pvid = dev->tag_protocol == DSA_TAG_PROTO_NONE;
 
+	/* The switch does not tell us the original VLAN for untagged
+	 * packets, so keep the CPU port always tagged.
+	 */
+	ds->untag_vlan_aware_bridge_pvid = true;
+
 	ret = b53_reset_switch(dev);
 	if (ret) {
 		dev_err(ds->dev, "failed to reset switch\n");
@@ -1545,6 +1550,9 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	if (vlan->vid == 0 && vlan->vid == b53_default_pvid(dev))
 		untagged = true;
 
+	if (vlan->vid > 0 && dsa_is_cpu_port(ds, port))
+		untagged = false;
+
 	vl->members |= BIT(port);
 	if (untagged && !b53_vlan_port_needs_forced_tagged(ds, port))
 		vl->untag |= BIT(port);
-- 
2.43.0

[PATCH net 03/11] net: dsa: b53: fix clearing PVID of a port

[Jonas Gorski]

Currently the PVID of ports are only set when adding/updating VLANs with
PVID set or removing VLANs, but not when clearing the PVID flag of a
VLAN.

E.g. the following flow

$ ip link add br0 type bridge vlan_filtering 1
$ ip link set sw1p1 master bridge
$ bridge vlan add dev sw1p1 vid 10 pvid untagged
$ bridge vlan add dev sw1p1 vid 10 untagged

Would keep the PVID set as 10, despite the flag being cleared. Fix this
by checking if we need to unset the PVID on vlan updates.

Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 9d4fb54b4ced..65d74c455c57 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1537,12 +1537,21 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
 	bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
 	struct b53_vlan *vl;
+	u16 old_pvid, new_pvid;
 	int err;
 
 	err = b53_vlan_prepare(ds, port, vlan);
 	if (err)
 		return err;
 
+	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &old_pvid);
+	if (pvid)
+		new_pvid = vlan->vid;
+	else if (!pvid && vlan->vid == old_pvid)
+		new_pvid = b53_default_pvid(dev);
+	else
+		new_pvid = old_pvid;
+
 	vl = &dev->vlans[vlan->vid];
 
 	b53_get_vlan_entry(dev, vlan->vid, vl);
@@ -1562,9 +1571,9 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	b53_set_vlan_entry(dev, vlan->vid, vl);
 	b53_fast_age_vlan(dev, vlan->vid);
 
-	if (pvid && !dsa_is_cpu_port(ds, port)) {
+	if (!dsa_is_cpu_port(ds, port) && new_pvid != old_pvid) {
 		b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port),
-			    vlan->vid);
+			    new_pvid);
 		b53_fast_age_vlan(dev, vlan->vid);
 	}
 
-- 
2.43.0

[PATCH net 04/11] net: dsa: b53: fix flushing old pvid VLAN on pvid change

[Jonas Gorski]

Presumably the intention here was to flush the VLAN of the old pvid, not
the added VLAN again, which we already flushed before.

Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 65d74c455c57..c67c0b5fbc1b 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1574,7 +1574,7 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	if (!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, vlan->vid);
+		b53_fast_age_vlan(dev, old_pvid);
 	}
 
 	return 0;
-- 
2.43.0

[PATCH net 05/11] net: dsa: b53: fix VLAN ID for untagged vlan on bridge leave

[Jonas Gorski]

The untagged default VLAN is added to the default vlan, which may be
one, but we modify the VLAN 0 entry on bridge leave.

Fix this to use the correct VLAN entry for the default pvid.

Fixes: fea83353177a ("net: dsa: b53: Fix default VLAN ID")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index c67c0b5fbc1b..c60b552b945c 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1986,7 +1986,7 @@ EXPORT_SYMBOL(b53_br_join);
 void b53_br_leave(struct dsa_switch *ds, int port, struct dsa_bridge bridge)
 {
 	struct b53_device *dev = ds->priv;
-	struct b53_vlan *vl = &dev->vlans[0];
+	struct b53_vlan *vl;
 	s8 cpu_port = dsa_to_port(ds, port)->cpu_dp->index;
 	unsigned int i;
 	u16 pvlan, reg, pvid;
@@ -2012,6 +2012,7 @@ void b53_br_leave(struct dsa_switch *ds, int port, struct dsa_bridge bridge)
 	dev->ports[port].vlan_ctl_mask = pvlan;
 
 	pvid = b53_default_pvid(dev);
+	vl = &dev->vlans[pvid];
 
 	/* Make this port join all VLANs without VLAN entries */
 	if (is58xx(dev)) {
-- 
2.43.0

[PATCH net 06/11] net: dsa: b53: always rejoin default untagged VLAN on bridge leave

[Jonas Gorski]

While JOIN_ALL_VLAN allows to join all VLANs, we still need to keep the
default VLAN enabled so that untagged traffic stays untagged.

So rejoin the default VLAN even for switches with JOIN_ALL_VLAN support.

Fixes: 48aea33a77ab ("net: dsa: b53: Add JOIN_ALL_VLAN support")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index c60b552b945c..4871e117f5ef 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -2021,12 +2021,12 @@ void b53_br_leave(struct dsa_switch *ds, int port, struct dsa_bridge bridge)
 		if (!(reg & BIT(cpu_port)))
 			reg |= BIT(cpu_port);
 		b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, reg);
-	} else {
-		b53_get_vlan_entry(dev, pvid, vl);
-		vl->members |= BIT(port) | BIT(cpu_port);
-		vl->untag |= BIT(port) | BIT(cpu_port);
-		b53_set_vlan_entry(dev, pvid, vl);
 	}
+
+	b53_get_vlan_entry(dev, pvid, vl);
+	vl->members |= BIT(port) | BIT(cpu_port);
+	vl->untag |= BIT(port) | BIT(cpu_port);
+	b53_set_vlan_entry(dev, pvid, vl);
 }
 EXPORT_SYMBOL(b53_br_leave);
 
-- 
2.43.0

[PATCH net 07/11] net: dsa: b53: do not allow to configure VLAN 0

[Jonas Gorski]

Since we cannot set forwarding destinations per VLAN, we should not have
a VLAN 0 configured, as it would allow untagged traffic to work across
ports on VLAN aware bridges regardless if a PVID untagged VLAN exists.

So remove the VLAN 0 on join, an re-add it on leave. But only do so if
we have a VLAN aware bridge, as without it, untagged traffic would
become tagged with VID 0 on a VLAN unaware bridge.

Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 36 ++++++++++++++++++++++++--------
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 4871e117f5ef..0b28791cca52 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1544,6 +1544,9 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	if (err)
 		return err;
 
+	if (vlan->vid == 0)
+		return 0;
+
 	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &old_pvid);
 	if (pvid)
 		new_pvid = vlan->vid;
@@ -1556,10 +1559,7 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 
 	b53_get_vlan_entry(dev, vlan->vid, vl);
 
-	if (vlan->vid == 0 && vlan->vid == b53_default_pvid(dev))
-		untagged = true;
-
-	if (vlan->vid > 0 && dsa_is_cpu_port(ds, port))
+	if (dsa_is_cpu_port(ds, port))
 		untagged = false;
 
 	vl->members |= BIT(port);
@@ -1589,6 +1589,9 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
 	struct b53_vlan *vl;
 	u16 pvid;
 
+	if (vlan->vid == 0)
+		return 0;
+
 	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &pvid);
 
 	vl = &dev->vlans[vlan->vid];
@@ -1935,8 +1938,9 @@ int b53_br_join(struct dsa_switch *ds, int port, struct dsa_bridge bridge,
 		bool *tx_fwd_offload, struct netlink_ext_ack *extack)
 {
 	struct b53_device *dev = ds->priv;
+	struct b53_vlan *vl;
 	s8 cpu_port = dsa_to_port(ds, port)->cpu_dp->index;
-	u16 pvlan, reg;
+	u16 pvlan, reg, pvid;
 	unsigned int i;
 
 	/* On 7278, port 7 which connects to the ASP should only receive
@@ -1945,6 +1949,9 @@ int b53_br_join(struct dsa_switch *ds, int port, struct dsa_bridge bridge,
 	if (dev->chip_id == BCM7278_DEVICE_ID && port == 7)
 		return -EINVAL;
 
+	pvid = b53_default_pvid(dev);
+	vl = &dev->vlans[pvid];
+
 	/* Make this port leave the all VLANs join since we will have proper
 	 * VLAN entries from now on
 	 */
@@ -1956,6 +1963,15 @@ int b53_br_join(struct dsa_switch *ds, int port, struct dsa_bridge bridge,
 		b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, reg);
 	}
 
+	if (ds->vlan_filtering) {
+		b53_get_vlan_entry(dev, pvid, vl);
+		vl->members &= ~BIT(port);
+		if (vl->members == BIT(cpu_port))
+			vl->members &= ~BIT(cpu_port);
+		vl->untag = vl->members;
+		b53_set_vlan_entry(dev, pvid, vl);
+	}
+
 	b53_read16(dev, B53_PVLAN_PAGE, B53_PVLAN_PORT_MASK(port), &pvlan);
 
 	b53_for_each_port(dev, i) {
@@ -2023,10 +2039,12 @@ void b53_br_leave(struct dsa_switch *ds, int port, struct dsa_bridge bridge)
 		b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, reg);
 	}
 
-	b53_get_vlan_entry(dev, pvid, vl);
-	vl->members |= BIT(port) | BIT(cpu_port);
-	vl->untag |= BIT(port) | BIT(cpu_port);
-	b53_set_vlan_entry(dev, pvid, vl);
+	if (ds->vlan_filtering) {
+		b53_get_vlan_entry(dev, pvid, vl);
+		vl->members |= BIT(port) | BIT(cpu_port);
+		vl->untag |= BIT(port) | BIT(cpu_port);
+		b53_set_vlan_entry(dev, pvid, vl);
+	}
 }
 EXPORT_SYMBOL(b53_br_leave);
 
-- 
2.43.0

[PATCH net 08/11] net: dsa: b53: do not program vlans when vlan filtering is off

[Jonas Gorski]

Documentation/networking/switchdev.rst says:

- with VLAN filtering turned off: the bridge is strictly VLAN unaware and its
  data path will process all Ethernet frames as if they are VLAN-untagged.
  The bridge VLAN database can still be modified, but the modifications should
  have no effect while VLAN filtering is turned off.

This breaks if we immediately apply the VLAN configuration, so skip
writing it when vlan_filtering is off.

Fixes: 0ee2af4ebbe3 ("net: dsa: set configure_vlan_while_not_filtering to true by default")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 48 +++++++++++++++++++-------------
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 0b28791cca52..ee2f1be62618 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1547,6 +1547,9 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	if (vlan->vid == 0)
 		return 0;
 
+	if (!ds->vlan_filtering)
+		return 0;
+
 	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &old_pvid);
 	if (pvid)
 		new_pvid = vlan->vid;
@@ -1592,6 +1595,9 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
 	if (vlan->vid == 0)
 		return 0;
 
+	if (!ds->vlan_filtering)
+		return 0;
+
 	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &pvid);
 
 	vl = &dev->vlans[vlan->vid];
@@ -1952,18 +1958,20 @@ int b53_br_join(struct dsa_switch *ds, int port, struct dsa_bridge bridge,
 	pvid = b53_default_pvid(dev);
 	vl = &dev->vlans[pvid];
 
-	/* Make this port leave the all VLANs join since we will have proper
-	 * VLAN entries from now on
-	 */
-	if (is58xx(dev)) {
-		b53_read16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, &reg);
-		reg &= ~BIT(port);
-		if ((reg & BIT(cpu_port)) == BIT(cpu_port))
-			reg &= ~BIT(cpu_port);
-		b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, reg);
-	}
-
 	if (ds->vlan_filtering) {
+		/* Make this port leave the all VLANs join since we will have
+		 * proper VLAN entries from now on
+		 */
+		if (is58xx(dev)) {
+			b53_read16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN,
+				   &reg);
+			reg &= ~BIT(port);
+			if ((reg & BIT(cpu_port)) == BIT(cpu_port))
+				reg &= ~BIT(cpu_port);
+			b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN,
+				    reg);
+		}
+
 		b53_get_vlan_entry(dev, pvid, vl);
 		vl->members &= ~BIT(port);
 		if (vl->members == BIT(cpu_port))
@@ -2030,16 +2038,16 @@ void b53_br_leave(struct dsa_switch *ds, int port, struct dsa_bridge bridge)
 	pvid = b53_default_pvid(dev);
 	vl = &dev->vlans[pvid];
 
-	/* Make this port join all VLANs without VLAN entries */
-	if (is58xx(dev)) {
-		b53_read16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, &reg);
-		reg |= BIT(port);
-		if (!(reg & BIT(cpu_port)))
-			reg |= BIT(cpu_port);
-		b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, reg);
-	}
-
 	if (ds->vlan_filtering) {
+		/* Make this port join all VLANs without VLAN entries */
+		if (is58xx(dev)) {
+			b53_read16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, &reg);
+			reg |= BIT(port);
+			if (!(reg & BIT(cpu_port)))
+				reg |= BIT(cpu_port);
+			b53_write16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, reg);
+		}
+
 		b53_get_vlan_entry(dev, pvid, vl);
 		vl->members |= BIT(port) | BIT(cpu_port);
 		vl->untag |= BIT(port) | BIT(cpu_port);
-- 
2.43.0

[PATCH net 09/11] net: dsa: b53: fix toggling vlan_filtering

[Jonas Gorski]

To allow runtime switching between vlan aware and vlan non-aware mode,
we need to properly keep track of any bridge VLAN configuration.
Likewise, we need to know when we actually switch between both modes, to
not have to rewrite the full VLAN table every time we update the VLANs.

So keep track of the current vlan_filtering mode, and on changes, apply
the appropriate VLAN configuration.

Fixes: 0ee2af4ebbe3 ("net: dsa: set configure_vlan_while_not_filtering to true by default")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 104 ++++++++++++++++++++++---------
 drivers/net/dsa/b53/b53_priv.h   |   2 +
 2 files changed, 75 insertions(+), 31 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index ee2f1be62618..0a7749b416f7 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -763,6 +763,22 @@ static bool b53_vlan_port_needs_forced_tagged(struct dsa_switch *ds, int port)
 	return dev->tag_protocol == DSA_TAG_PROTO_NONE && dsa_is_cpu_port(ds, port);
 }
 
+static bool b53_vlan_port_may_join_untagged(struct dsa_switch *ds, int port)
+{
+	struct b53_device *dev = ds->priv;
+	struct dsa_port *dp;
+
+	if (!dev->vlan_filtering)
+		return true;
+
+	dp = dsa_to_port(ds, port);
+
+	if (dsa_port_is_cpu(dp))
+		return true;
+
+	return dp->bridge == NULL;
+}
+
 int b53_configure_vlan(struct dsa_switch *ds)
 {
 	struct b53_device *dev = ds->priv;
@@ -781,7 +797,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, ds->vlan_filtering);
+	b53_enable_vlan(dev, -1, dev->vlan_enabled, 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
@@ -789,26 +805,39 @@ int b53_configure_vlan(struct dsa_switch *ds)
 	 * entry. Do this only when the tagging protocol is not
 	 * DSA_TAG_PROTO_NONE
 	 */
+	v = &dev->vlans[def_vid];
 	b53_for_each_port(dev, i) {
-		v = &dev->vlans[def_vid];
-		v->members |= BIT(i);
+		if (!b53_vlan_port_may_join_untagged(ds, i))
+			continue;
+
+		vl.members |= BIT(i);
 		if (!b53_vlan_port_needs_forced_tagged(ds, i))
-			v->untag = v->members;
-		b53_write16(dev, B53_VLAN_PAGE,
-			    B53_VLAN_PORT_DEF_TAG(i), def_vid);
+			vl.untag = vl.members;
+		b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(i),
+			    def_vid);
 	}
+	b53_set_vlan_entry(dev, def_vid, &vl);
 
-	/* 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; vid < dev->num_vlans; vid++) {
-		v = &dev->vlans[vid];
+	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];
 
-		if (!v->members)
-			continue;
+			if (!v->members)
+				continue;
+
+			b53_set_vlan_entry(dev, vid, v);
+			b53_fast_age_vlan(dev, vid);
+		}
 
-		b53_set_vlan_entry(dev, vid, v);
-		b53_fast_age_vlan(dev, vid);
+		b53_for_each_port(dev, i) {
+			if (!dsa_is_cpu_port(ds, i))
+				b53_write16(dev, B53_VLAN_PAGE,
+					    B53_VLAN_PORT_DEF_TAG(i),
+					    dev->ports[i].pvid);
+		}
 	}
 
 	return 0;
@@ -1127,7 +1156,9 @@ EXPORT_SYMBOL(b53_setup_devlink_resources);
 static int b53_setup(struct dsa_switch *ds)
 {
 	struct b53_device *dev = ds->priv;
+	struct b53_vlan *vl;
 	unsigned int port;
+	u16 pvid;
 	int ret;
 
 	/* Request bridge PVID untagged when DSA_TAG_PROTO_NONE is set
@@ -1146,6 +1177,15 @@ static int b53_setup(struct dsa_switch *ds)
 		return ret;
 	}
 
+	/* setup default vlan for filtering mode */
+	pvid = b53_default_pvid(dev);
+	vl = &dev->vlans[pvid];
+	b53_for_each_port(dev, port) {
+		vl->members |= BIT(port);
+		if (!b53_vlan_port_needs_forced_tagged(ds, port))
+			vl->untag |= BIT(port);
+	}
+
 	b53_reset_mib(dev);
 
 	ret = b53_apply_config(dev);
@@ -1499,7 +1539,10 @@ int b53_vlan_filtering(struct dsa_switch *ds, int port, bool vlan_filtering,
 {
 	struct b53_device *dev = ds->priv;
 
-	b53_enable_vlan(dev, port, dev->vlan_enabled, vlan_filtering);
+	if (dev->vlan_filtering != vlan_filtering) {
+		dev->vlan_filtering = vlan_filtering;
+		b53_apply_config(dev);
+	}
 
 	return 0;
 }
@@ -1524,7 +1567,7 @@ static int b53_vlan_prepare(struct dsa_switch *ds, int port,
 	if (vlan->vid >= dev->num_vlans)
 		return -ERANGE;
 
-	b53_enable_vlan(dev, port, true, ds->vlan_filtering);
+	b53_enable_vlan(dev, port, true, dev->vlan_filtering);
 
 	return 0;
 }
@@ -1547,21 +1590,17 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	if (vlan->vid == 0)
 		return 0;
 
-	if (!ds->vlan_filtering)
-		return 0;
-
-	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &old_pvid);
+	old_pvid = dev->ports[port].pvid;
 	if (pvid)
 		new_pvid = vlan->vid;
 	else if (!pvid && vlan->vid == old_pvid)
 		new_pvid = b53_default_pvid(dev);
 	else
 		new_pvid = old_pvid;
+	dev->ports[port].pvid = new_pvid;
 
 	vl = &dev->vlans[vlan->vid];
 
-	b53_get_vlan_entry(dev, vlan->vid, vl);
-
 	if (dsa_is_cpu_port(ds, port))
 		untagged = false;
 
@@ -1571,6 +1610,9 @@ int b53_vlan_add(struct dsa_switch *ds, int port,
 	else
 		vl->untag &= ~BIT(port);
 
+	if (!dev->vlan_filtering)
+		return 0;
+
 	b53_set_vlan_entry(dev, vlan->vid, vl);
 	b53_fast_age_vlan(dev, vlan->vid);
 
@@ -1595,23 +1637,22 @@ int b53_vlan_del(struct dsa_switch *ds, int port,
 	if (vlan->vid == 0)
 		return 0;
 
-	if (!ds->vlan_filtering)
-		return 0;
-
-	b53_read16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(port), &pvid);
+	pvid = dev->ports[port].pvid;
 
 	vl = &dev->vlans[vlan->vid];
 
-	b53_get_vlan_entry(dev, vlan->vid, vl);
-
 	vl->members &= ~BIT(port);
 
 	if (pvid == vlan->vid)
 		pvid = b53_default_pvid(dev);
+	dev->ports[port].pvid = pvid;
 
 	if (untagged && !b53_vlan_port_needs_forced_tagged(ds, port))
 		vl->untag &= ~(BIT(port));
 
+	if (!dev->vlan_filtering)
+		return 0;
+
 	b53_set_vlan_entry(dev, vlan->vid, vl);
 	b53_fast_age_vlan(dev, vlan->vid);
 
@@ -1958,7 +1999,7 @@ int b53_br_join(struct dsa_switch *ds, int port, struct dsa_bridge bridge,
 	pvid = b53_default_pvid(dev);
 	vl = &dev->vlans[pvid];
 
-	if (ds->vlan_filtering) {
+	if (dev->vlan_filtering) {
 		/* Make this port leave the all VLANs join since we will have
 		 * proper VLAN entries from now on
 		 */
@@ -2038,7 +2079,7 @@ void b53_br_leave(struct dsa_switch *ds, int port, struct dsa_bridge bridge)
 	pvid = b53_default_pvid(dev);
 	vl = &dev->vlans[pvid];
 
-	if (ds->vlan_filtering) {
+	if (dev->vlan_filtering) {
 		/* Make this port join all VLANs without VLAN entries */
 		if (is58xx(dev)) {
 			b53_read16(dev, B53_VLAN_PAGE, B53_JOIN_ALL_VLAN_EN, &reg);
@@ -2803,6 +2844,7 @@ struct b53_device *b53_switch_alloc(struct device *base,
 	ds->ops = &b53_switch_ops;
 	ds->phylink_mac_ops = &b53_phylink_mac_ops;
 	dev->vlan_enabled = true;
+	dev->vlan_filtering = false;
 	/* Let DSA handle the case were multiple bridges span the same switch
 	 * device and different VLAN awareness settings are requested, which
 	 * would be breaking filtering semantics for any of the other bridge
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 0166c37a13a7..4636e27fd1ee 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -96,6 +96,7 @@ struct b53_pcs {
 
 struct b53_port {
 	u16		vlan_ctl_mask;
+	u16		pvid;
 	struct ethtool_keee eee;
 };
 
@@ -147,6 +148,7 @@ struct b53_device {
 	unsigned int num_vlans;
 	struct b53_vlan *vlans;
 	bool vlan_enabled;
+	bool vlan_filtering;
 	unsigned int num_ports;
 	struct b53_port *ports;
 
-- 
2.43.0

[PATCH net 10/11] net: dsa: b53: fix learning on VLAN unaware bridges

[Jonas Gorski]

When VLAN filtering is off, we configure the switch to forward, but not
learn on VLAN table misses. This effectively disables learning while not
filtering.

Fix this by switching to forward and learn. Setting the learning disable
register will still control whether learning actually happens.

Fixes: dad8d7c6452b ("net: dsa: b53: Properly account for VLAN filtering")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 0a7749b416f7..a2c0b44fc6be 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -383,7 +383,7 @@ static void b53_enable_vlan(struct b53_device *dev, int port, bool enable,
 			vc4 |= VC4_ING_VID_VIO_DROP << VC4_ING_VID_CHECK_S;
 			vc5 |= VC5_DROP_VTABLE_MISS;
 		} else {
-			vc4 |= VC4_ING_VID_VIO_FWD << VC4_ING_VID_CHECK_S;
+			vc4 |= VC4_NO_ING_VID_CHK << VC4_ING_VID_CHECK_S;
 			vc5 &= ~VC5_DROP_VTABLE_MISS;
 		}
 
-- 
2.43.0

[PATCH net 11/11] net: dsa: b53: do not set learning and unicast/multicast on up

[Jonas Gorski]

When a port gets set up, b53 disables learning and enables the port for
flooding. This can undo any bridge configuration on the port.

E.g. the following flow would disable learning on a port:

$ ip link add br0 type bridge
$ ip link set sw1p1 master br0 <- enables learning for sw1p1
$ ip link set br0 up
$ ip link set sw1p1 up <- disables learning again

Fix this by populating dsa_switch_ops::port_setup(), and set up initial
config there.

Fixes: f9b3827ee66c ("net: dsa: b53: Support setting learning on port")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
---
 drivers/net/dsa/b53/b53_common.c | 21 +++++++++++++--------
 drivers/net/dsa/b53/b53_priv.h   |  1 +
 drivers/net/dsa/bcm_sf2.c        |  1 +
 3 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index a2c0b44fc6be..9eb39cfa5fb2 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -578,6 +578,18 @@ static void b53_eee_enable_set(struct dsa_switch *ds, int port, bool enable)
 	b53_write16(dev, B53_EEE_PAGE, B53_EEE_EN_CTRL, reg);
 }
 
+int b53_setup_port(struct dsa_switch *ds, int port)
+{
+	struct b53_device *dev = ds->priv;
+
+	b53_port_set_ucast_flood(dev, port, true);
+	b53_port_set_mcast_flood(dev, port, true);
+	b53_port_set_learning(dev, port, false);
+
+	return 0;
+}
+EXPORT_SYMBOL(b53_setup_port);
+
 int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
 {
 	struct b53_device *dev = ds->priv;
@@ -590,10 +602,6 @@ int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy)
 
 	cpu_port = dsa_to_port(ds, port)->cpu_dp->index;
 
-	b53_port_set_ucast_flood(dev, port, true);
-	b53_port_set_mcast_flood(dev, port, true);
-	b53_port_set_learning(dev, port, false);
-
 	if (dev->ops->irq_enable)
 		ret = dev->ops->irq_enable(dev, port);
 	if (ret)
@@ -724,10 +732,6 @@ static void b53_enable_cpu_port(struct b53_device *dev, int port)
 	b53_write8(dev, B53_CTRL_PAGE, B53_PORT_CTRL(port), port_ctrl);
 
 	b53_brcm_hdr_setup(dev->ds, port);
-
-	b53_port_set_ucast_flood(dev, port, true);
-	b53_port_set_mcast_flood(dev, port, true);
-	b53_port_set_learning(dev, port, false);
 }
 
 static void b53_enable_mib(struct b53_device *dev)
@@ -2387,6 +2391,7 @@ static const struct dsa_switch_ops b53_switch_ops = {
 	.phy_read		= b53_phy_read16,
 	.phy_write		= b53_phy_write16,
 	.phylink_get_caps	= b53_phylink_get_caps,
+	.port_setup		= b53_setup_port,
 	.port_enable		= b53_enable_port,
 	.port_disable		= b53_disable_port,
 	.support_eee		= b53_support_eee,
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 4636e27fd1ee..2cf3e6a81e37 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -384,6 +384,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds, int port,
 					   enum dsa_tag_protocol mprot);
 void b53_mirror_del(struct dsa_switch *ds, int port,
 		    struct dsa_mall_mirror_tc_entry *mirror);
+int b53_setup_port(struct dsa_switch *ds, int port);
 int b53_enable_port(struct dsa_switch *ds, int port, struct phy_device *phy);
 void b53_disable_port(struct dsa_switch *ds, int port);
 void b53_brcm_hdr_setup(struct dsa_switch *ds, int port);
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index fa2bf3fa9019..454a8c7fd7ee 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1230,6 +1230,7 @@ static const struct dsa_switch_ops bcm_sf2_ops = {
 	.resume			= bcm_sf2_sw_resume,
 	.get_wol		= bcm_sf2_sw_get_wol,
 	.set_wol		= bcm_sf2_sw_set_wol,
+	.port_setup		= b53_setup_port,
 	.port_enable		= bcm_sf2_port_setup,
 	.port_disable		= bcm_sf2_port_disable,
 	.support_eee		= b53_support_eee,
-- 
2.43.0

Re: [PATCH net 04/11] net: dsa: b53: fix flushing old pvid VLAN on pvid change

[Florian Fainelli]

On 4/29/2025 10:17 PM, Jonas Gorski wrote:
> Presumably the intention here was to flush the VLAN of the old pvid, not
> the added VLAN again, which we already flushed before.
> 
> Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>

Does not this logically belong to patch #3?
-- 
Florian

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Florian Fainelli]

On 4/29/2025 10:16 PM, Jonas Gorski wrote:
> This patchset aims at fixing most issues observed while running the
> vlan_unaware_bridge, vlan_aware_bridge and local_termination selftests.
> 
> Most tests succeed with these patches on BCM53115, connected to a
> BCM6368.
> 
> It took me a while to figure out that a lot of tests will fail if all
> ports have the same MAC address, as the switches drop any frames with
> DA == SA. Luckily BCM63XX boards often have enough MACs allocated for
> all ports, so I just needed to assign them.
> 
> The still failing tests are:
> 
> FDB learning, both vlan aware aware and unaware:
> 
> This is expected, as b53 currently does not implement changing the
> ageing time, and both the bridge code and DSA ignore that, so the
> learned entries don't age out as expected.
> 
> ping and ping6 in vlan unaware:
> 
> These fail because of the now fixed learning, the switch trying to
> forward packet ingressing on one of the standalone ports to the learned
> port of the mac address when the packets ingressed on the bridged port.

Sorry not quite getting that part, can you expand a bit more?

> 
> The port VLAN masks only prevent forwarding to other ports, but the ARL
> lookup will still happen, and the packet gets dropped because the port
> isn't allowed to forward there.

OK.

> 
> I have a fix/workaround for that, but as it is a bit more controversial
> and makes use of an unrelated feature, I decided to hold off from that
> and post it later.

Can you expand on the fix/workaround you have?

> 
> This wasn't noticed so far, because learning was never working in VLAN
> unaware mode, so the traffic was always broadcast (which sidesteps the
> issue).
> 
> Finally some of the multicast tests from local_termination fail, where
> the reception worked except it shouldn't. This doesn't seem to me as a
> super serious issue, so I didn't attempt to debug/fix these yet.
> 
> I'm not super confident I didn't break sf2 along the way, but I did
> compile test and tried to find ways it cause issues (I failed to find
> any). I hope Florian will tell me.

I am currently out of the office but intend to test your patch series at 
some point in the next few days. Let's gather some review feedback in 
the meantime, thanks for submitting those fixes!
-- 
Florian

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Jonas Gorski]

On Wed, Apr 30, 2025 at 10:07 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
>
>
>
> On 4/29/2025 10:16 PM, Jonas Gorski wrote:
> > This patchset aims at fixing most issues observed while running the
> > vlan_unaware_bridge, vlan_aware_bridge and local_termination selftests.
> >
> > Most tests succeed with these patches on BCM53115, connected to a
> > BCM6368.
> >
> > It took me a while to figure out that a lot of tests will fail if all
> > ports have the same MAC address, as the switches drop any frames with
> > DA == SA. Luckily BCM63XX boards often have enough MACs allocated for
> > all ports, so I just needed to assign them.
> >
> > The still failing tests are:
> >
> > FDB learning, both vlan aware aware and unaware:
> >
> > This is expected, as b53 currently does not implement changing the
> > ageing time, and both the bridge code and DSA ignore that, so the
> > learned entries don't age out as expected.
> >
> > ping and ping6 in vlan unaware:
> >
> > These fail because of the now fixed learning, the switch trying to
> > forward packet ingressing on one of the standalone ports to the learned
> > port of the mac address when the packets ingressed on the bridged port.
>
> Sorry not quite getting that part, can you expand a bit more?

The ping test uses four network ports, where two pairs are linked via
a network cable. So the setup is

sw1p1 <- cable -> sw1p2 <- bridge -> sw1p3 <- cable ->sw1p4

And it tries to ping from sw1p1 to sw1p4.

In the vlan_aware test, the bridge uses VLAN 1 pvid untagged, so it
learns in VLAN 1, while the standalone ports use VLAN 0. Different
FIDs, so no issue.

In the vlan_unaware test, untagged traffic uses VLAN 0 everywhere, so
the following happens:

- switch learns swp1p's MAC at sw1p2
- switch learns sw1p4's MAC at sw1p3

when sw1p1 sends a unicast to sw1p4' mac it egresses on swp1p3 and
then ingresses on sw1p4 again. The switch see's sw1p2's MAC as DA and
then ARL lookup says "sw1p3", but the port VLAN mask disallows sending
from sw1p4 to sw1p3, so it gets dropped.

Without learning, all packets are flooded, so connectivity works, as
the standalone ports are always part of the flood masks.

> > The port VLAN masks only prevent forwarding to other ports, but the ARL
> > lookup will still happen, and the packet gets dropped because the port
> > isn't allowed to forward there.
>
> OK.
>
> >
> > I have a fix/workaround for that, but as it is a bit more controversial
> > and makes use of an unrelated feature, I decided to hold off from that
> > and post it later.
>
> Can you expand on the fix/workaround you have?

It's setting EAP mode to simplified on standalone ports, where it
redirects all frames to the CPU port where there is no matching ARL
entry for that SA and port. That should work on everything semi recent
(including BCM63XX), and should work regardless of VLAN. It might
cause more traffic than expected to be sent to the switch, as I'm not
sure if multicast filtering would still work (not that I'm sure that
it currently works lol).

At first I moved standalone ports to VID 4095 for untagged traffic,
but that only fixed the issue for untagged traffic, and you would have
had the same issue again when using VLAN uppers. And VLAN uppers have
the same issue on vlan aware bridges, so the above would be a more
complete workaround.

> > This wasn't noticed so far, because learning was never working in VLAN
> > unaware mode, so the traffic was always broadcast (which sidesteps the
> > issue).
> >
> > Finally some of the multicast tests from local_termination fail, where
> > the reception worked except it shouldn't. This doesn't seem to me as a
> > super serious issue, so I didn't attempt to debug/fix these yet.
> >
> > I'm not super confident I didn't break sf2 along the way, but I did
> > compile test and tried to find ways it cause issues (I failed to find
> > any). I hope Florian will tell me.
>
> I am currently out of the office but intend to test your patch series at
> some point in the next few days. Let's gather some review feedback in
> the meantime, thanks for submitting those fixes!

If you are awake at this hour I guess your are back "home" ;-)

Sure thing, take your time! All I wanted to implement is MST support,
but then I noticed some things not working as expected, and then I
became aware of the selftests, and then I suddenly had accumulated a
lot of fixes trying to make everything say "Okay" (and sometimes
wondering why other stuff broke when I fixed things, like the learning
in unaware mode).

Best regards,
Jonas

Re: [PATCH net 04/11] net: dsa: b53: fix flushing old pvid VLAN on pvid change

[Jonas Gorski]

On Wed, Apr 30, 2025 at 10:03 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
>
>
>
> On 4/29/2025 10:17 PM, Jonas Gorski wrote:
> > Presumably the intention here was to flush the VLAN of the old pvid, not
> > the added VLAN again, which we already flushed before.
> >
> > Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support")
> > Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
>
> Does not this logically belong to patch #3?

Yes and no, IMHO these are two different issues, though closely related.

The flush was always there, and for a long time I wondered why we
flush vlan->vid again. Until I noticed that PVID clears aren't handled
(as a test broke because of that), and then I understood what the
intention of the second flush was.

But I should probably reorder them and first fix flushing of the old
pvid, and then add the handling of unsetting pvid.

Also at one point we might want to limit the flushing of the VID to
just that on that port, but that is a future optimization. I fought
very hard the temptation to include optimizations/refactorings that
don't actually fix things, and will send them at a later time.

Best regards,
Jonas

Re: [PATCH net 09/11] net: dsa: b53: fix toggling vlan_filtering

[Paolo Abeni]

On 4/29/25 10:17 PM, Jonas Gorski wrote:
> @@ -789,26 +805,39 @@ int b53_configure_vlan(struct dsa_switch *ds)
>  	 * entry. Do this only when the tagging protocol is not
>  	 * DSA_TAG_PROTO_NONE
>  	 */
> +	v = &dev->vlans[def_vid];
>  	b53_for_each_port(dev, i) {
> -		v = &dev->vlans[def_vid];
> -		v->members |= BIT(i);
> +		if (!b53_vlan_port_may_join_untagged(ds, i))
> +			continue;
> +
> +		vl.members |= BIT(i);
>  		if (!b53_vlan_port_needs_forced_tagged(ds, i))
> -			v->untag = v->members;
> -		b53_write16(dev, B53_VLAN_PAGE,
> -			    B53_VLAN_PORT_DEF_TAG(i), def_vid);
> +			vl.untag = vl.members;
> +		b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(i),
> +			    def_vid);
>  	}
> +	b53_set_vlan_entry(dev, def_vid, &vl);
>  
> -	/* 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; vid < dev->num_vlans; vid++) {
> -		v = &dev->vlans[vid];
> +	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];
>  
> -		if (!v->members)
> -			continue;
> +			if (!v->members)
> +				continue;
> +
> +			b53_set_vlan_entry(dev, vid, v);
> +			b53_fast_age_vlan(dev, vid);
> +		}
>  
> -		b53_set_vlan_entry(dev, vid, v);
> -		b53_fast_age_vlan(dev, vid);
> +		b53_for_each_port(dev, i) {
> +			if (!dsa_is_cpu_port(ds, i))
> +				b53_write16(dev, B53_VLAN_PAGE,
> +					    B53_VLAN_PORT_DEF_TAG(i),
> +					    dev->ports[i].pvid);

Just if you have to repost for other reasons:
			if (dsa_is_cpu_port(ds, i))
				continue;

			b53_write16(dev, B53_VLAN_PAGE, //...

should probably be more readable.

BTW, @Florian: any deadline for testing feedback on this?

Thanks,

Paolo

Re: [PATCH net 09/11] net: dsa: b53: fix toggling vlan_filtering

[Florian Fainelli]

On 5/6/2025 9:51 AM, Paolo Abeni wrote:
> On 4/29/25 10:17 PM, Jonas Gorski wrote:
>> @@ -789,26 +805,39 @@ int b53_configure_vlan(struct dsa_switch *ds)
>>   	 * entry. Do this only when the tagging protocol is not
>>   	 * DSA_TAG_PROTO_NONE
>>   	 */
>> +	v = &dev->vlans[def_vid];
>>   	b53_for_each_port(dev, i) {
>> -		v = &dev->vlans[def_vid];
>> -		v->members |= BIT(i);
>> +		if (!b53_vlan_port_may_join_untagged(ds, i))
>> +			continue;
>> +
>> +		vl.members |= BIT(i);
>>   		if (!b53_vlan_port_needs_forced_tagged(ds, i))
>> -			v->untag = v->members;
>> -		b53_write16(dev, B53_VLAN_PAGE,
>> -			    B53_VLAN_PORT_DEF_TAG(i), def_vid);
>> +			vl.untag = vl.members;
>> +		b53_write16(dev, B53_VLAN_PAGE, B53_VLAN_PORT_DEF_TAG(i),
>> +			    def_vid);
>>   	}
>> +	b53_set_vlan_entry(dev, def_vid, &vl);
>>   
>> -	/* 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; vid < dev->num_vlans; vid++) {
>> -		v = &dev->vlans[vid];
>> +	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];
>>   
>> -		if (!v->members)
>> -			continue;
>> +			if (!v->members)
>> +				continue;
>> +
>> +			b53_set_vlan_entry(dev, vid, v);
>> +			b53_fast_age_vlan(dev, vid);
>> +		}
>>   
>> -		b53_set_vlan_entry(dev, vid, v);
>> -		b53_fast_age_vlan(dev, vid);
>> +		b53_for_each_port(dev, i) {
>> +			if (!dsa_is_cpu_port(ds, i))
>> +				b53_write16(dev, B53_VLAN_PAGE,
>> +					    B53_VLAN_PORT_DEF_TAG(i),
>> +					    dev->ports[i].pvid);
> 
> Just if you have to repost for other reasons:
> 			if (dsa_is_cpu_port(ds, i))
> 				continue;
> 
> 			b53_write16(dev, B53_VLAN_PAGE, //...
> 
> should probably be more readable.
> 
> BTW, @Florian: any deadline for testing feedback on this?

Trying to enjoy some time off until May 17th, depending upon the weather 
I might be able to get this tested before the end of this week.
-- 
Florian

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Florian Fainelli]

On 4/29/2025 10:16 PM, Jonas Gorski wrote:
> This patchset aims at fixing most issues observed while running the
> vlan_unaware_bridge, vlan_aware_bridge and local_termination selftests.
> 
> Most tests succeed with these patches on BCM53115, connected to a
> BCM6368.
> 
> It took me a while to figure out that a lot of tests will fail if all
> ports have the same MAC address, as the switches drop any frames with
> DA == SA. Luckily BCM63XX boards often have enough MACs allocated for
> all ports, so I just needed to assign them.
> 
> The still failing tests are:
> 
> FDB learning, both vlan aware aware and unaware:
> 
> This is expected, as b53 currently does not implement changing the
> ageing time, and both the bridge code and DSA ignore that, so the
> learned entries don't age out as expected.
> 
> ping and ping6 in vlan unaware:
> 
> These fail because of the now fixed learning, the switch trying to
> forward packet ingressing on one of the standalone ports to the learned
> port of the mac address when the packets ingressed on the bridged port.
> 
> The port VLAN masks only prevent forwarding to other ports, but the ARL
> lookup will still happen, and the packet gets dropped because the port
> isn't allowed to forward there.
> 
> I have a fix/workaround for that, but as it is a bit more controversial
> and makes use of an unrelated feature, I decided to hold off from that
> and post it later.
> 
> This wasn't noticed so far, because learning was never working in VLAN
> unaware mode, so the traffic was always broadcast (which sidesteps the
> issue).
> 
> Finally some of the multicast tests from local_termination fail, where
> the reception worked except it shouldn't. This doesn't seem to me as a
> super serious issue, so I didn't attempt to debug/fix these yet.
> 
> I'm not super confident I didn't break sf2 along the way, but I did
> compile test and tried to find ways it cause issues (I failed to find
> any). I hope Florian will tell me.

For this series, using a combination of VLAN aware and unaware bridge, 
standalone ports with 802.1q uppers on top, thanks Jonas!

Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Vladimir Oltean]

/ unrelated to patches /

On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
> > > I have a fix/workaround for that, but as it is a bit more controversial
> > > and makes use of an unrelated feature, I decided to hold off from that
> > > and post it later.
> >
> > Can you expand on the fix/workaround you have?
> 
> It's setting EAP mode to simplified on standalone ports, where it
> redirects all frames to the CPU port where there is no matching ARL
> entry for that SA and port. That should work on everything semi recent
> (including BCM63XX), and should work regardless of VLAN. It might
> cause more traffic than expected to be sent to the switch, as I'm not
> sure if multicast filtering would still work (not that I'm sure that
> it currently works lol).
> 
> At first I moved standalone ports to VID 4095 for untagged traffic,
> but that only fixed the issue for untagged traffic, and you would have
> had the same issue again when using VLAN uppers. And VLAN uppers have
> the same issue on vlan aware bridges, so the above would be a more
> complete workaround.

I don't understand the logic, can you explain "you would have had the
same issue again when using VLAN uppers"? The original issue, as you
presented it, is with bridges with vlan_filtering=0, and does not exist
with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
not committed to hardware RX filters. And bridges with mixed
vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
So I don't see how making VID 4095 be the PVID of just standalone ports
(leaving VLAN-unaware bridge ports with a different VID) would not be
sufficient for the presented problem.

That being said, trapping to CPU all packets on standalone ports is not
uncontroversial, as long as it works correctly for the hardware
controlled by this driver. You seem concerned about losing RX filtering,
but if you look at dsa_switch_supports_uc_filtering() and
dsa_switch_supports_mc_filtering() you'll see b53 never had it - it
depends, among other things, on ds->fdb_isolation == true and
ds->vlan_filtering_is_global == false. Here you're working on improving
the fdb_isolation requirements, but there is still no support in the
core for devices where VLAN filtering is a global setting.

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Jonas Gorski]

On Tue, May 6, 2025 at 3:42 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>
> / unrelated to patches /
>
> On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
> > > > I have a fix/workaround for that, but as it is a bit more controversial
> > > > and makes use of an unrelated feature, I decided to hold off from that
> > > > and post it later.
> > >
> > > Can you expand on the fix/workaround you have?
> >
> > It's setting EAP mode to simplified on standalone ports, where it
> > redirects all frames to the CPU port where there is no matching ARL
> > entry for that SA and port. That should work on everything semi recent
> > (including BCM63XX), and should work regardless of VLAN. It might
> > cause more traffic than expected to be sent to the switch, as I'm not
> > sure if multicast filtering would still work (not that I'm sure that
> > it currently works lol).
> >
> > At first I moved standalone ports to VID 4095 for untagged traffic,
> > but that only fixed the issue for untagged traffic, and you would have
> > had the same issue again when using VLAN uppers. And VLAN uppers have
> > the same issue on vlan aware bridges, so the above would be a more
> > complete workaround.
>
> I don't understand the logic, can you explain "you would have had the
> same issue again when using VLAN uppers"? The original issue, as you
> presented it, is with bridges with vlan_filtering=0, and does not exist
> with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
> not committed to hardware RX filters. And bridges with mixed
> vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
> So I don't see how making VID 4095 be the PVID of just standalone ports
> (leaving VLAN-unaware bridge ports with a different VID) would not be
> sufficient for the presented problem.

The issue isn't the vlan filtering, it's the (missing) FDB isolation
on the ASIC.

In general if a MAC is learned on one of the bridged ports, the ASIC
will try to forward any traffic ingressing for that MAC to the port
according to the internal FDB regardless if the source port is bridged
or not. The private VLAN masks used to isolate ports is only applied
*after* the forwarding lookup was done (this is how the hardware
works), and will then cause traffic to be dropped on standalone ports.

So for vlan_aware=0, the bridge learns on the FDB for VID 0, which is
also used for untagged traffic on stand alone ports, so the issue
happens.

For vlan_aware=1, untagged traffic is assigned to a VLAN != 0 on the
bridge, so the FDBs are different. Therefore no issue.

But once using VLAN uppers, the FDB will be the same again on the
bridged ports and tagged traffic on the standalone ports, so it
happens again. And this would be true regardless of vlan_aware or not.

Therefore using VID 4095 would only avoid the issue for vlan_aware=0
and untagged, but not the VLAN upper scenario.

Unfortunately there is no bit to disable FDB lookups for standalone
ports, only learning (at least I haven't found one).

> That being said, trapping to CPU all packets on standalone ports is not
> uncontroversial, as long as it works correctly for the hardware
> controlled by this driver. You seem concerned about losing RX filtering,
> but if you look at dsa_switch_supports_uc_filtering() and
> dsa_switch_supports_mc_filtering() you'll see b53 never had it - it
> depends, among other things, on ds->fdb_isolation == true and
> ds->vlan_filtering_is_global == false. Here you're working on improving
> the fdb_isolation requirements, but there is still no support in the
> core for devices where VLAN filtering is a global setting.

Aha, so I don't need to care about this, since fdb_isolation is not
supported and filtering is always global. Good to know.

I'm mostly concerned if using the security feature for that has any
side effects I'm not aware of (e.g. dropping of some traffic), or if
it would prevent using it for its intended use, i.e. locked ports and
MAB. I don't trust it yet, feels a bit too easy of a solution ;-).
Will need to double/triple check (and read the docs).

Also it's not supported by all b53 supported ASICs, so maybe there is
a solution that works for all (but most probably there is not).

Best regards,
Jonas

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Florian Fainelli]

On 5/6/2025 4:27 PM, Jonas Gorski wrote:
> On Tue, May 6, 2025 at 3:42 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>>
>> / unrelated to patches /
>>
>> On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
>>>>> I have a fix/workaround for that, but as it is a bit more controversial
>>>>> and makes use of an unrelated feature, I decided to hold off from that
>>>>> and post it later.
>>>>
>>>> Can you expand on the fix/workaround you have?
>>>
>>> It's setting EAP mode to simplified on standalone ports, where it
>>> redirects all frames to the CPU port where there is no matching ARL
>>> entry for that SA and port. That should work on everything semi recent
>>> (including BCM63XX), and should work regardless of VLAN. It might
>>> cause more traffic than expected to be sent to the switch, as I'm not
>>> sure if multicast filtering would still work (not that I'm sure that
>>> it currently works lol).
>>>
>>> At first I moved standalone ports to VID 4095 for untagged traffic,
>>> but that only fixed the issue for untagged traffic, and you would have
>>> had the same issue again when using VLAN uppers. And VLAN uppers have
>>> the same issue on vlan aware bridges, so the above would be a more
>>> complete workaround.
>>
>> I don't understand the logic, can you explain "you would have had the
>> same issue again when using VLAN uppers"? The original issue, as you
>> presented it, is with bridges with vlan_filtering=0, and does not exist
>> with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
>> not committed to hardware RX filters. And bridges with mixed
>> vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
>> So I don't see how making VID 4095 be the PVID of just standalone ports
>> (leaving VLAN-unaware bridge ports with a different VID) would not be
>> sufficient for the presented problem.
> 
> The issue isn't the vlan filtering, it's the (missing) FDB isolation
> on the ASIC.

Could not we just use double tagging to overcome that limitation?
-- 
Florian

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Jonas Gorski]

On Tue, May 6, 2025 at 9:03 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> On 5/6/2025 4:27 PM, Jonas Gorski wrote:
> > On Tue, May 6, 2025 at 3:42 PM Vladimir Oltean <olteanv@gmail.com> wrote:
> >>
> >> / unrelated to patches /
> >>
> >> On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
> >>>>> I have a fix/workaround for that, but as it is a bit more controversial
> >>>>> and makes use of an unrelated feature, I decided to hold off from that
> >>>>> and post it later.
> >>>>
> >>>> Can you expand on the fix/workaround you have?
> >>>
> >>> It's setting EAP mode to simplified on standalone ports, where it
> >>> redirects all frames to the CPU port where there is no matching ARL
> >>> entry for that SA and port. That should work on everything semi recent
> >>> (including BCM63XX), and should work regardless of VLAN. It might
> >>> cause more traffic than expected to be sent to the switch, as I'm not
> >>> sure if multicast filtering would still work (not that I'm sure that
> >>> it currently works lol).
> >>>
> >>> At first I moved standalone ports to VID 4095 for untagged traffic,
> >>> but that only fixed the issue for untagged traffic, and you would have
> >>> had the same issue again when using VLAN uppers. And VLAN uppers have
> >>> the same issue on vlan aware bridges, so the above would be a more
> >>> complete workaround.
> >>
> >> I don't understand the logic, can you explain "you would have had the
> >> same issue again when using VLAN uppers"? The original issue, as you
> >> presented it, is with bridges with vlan_filtering=0, and does not exist
> >> with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
> >> not committed to hardware RX filters. And bridges with mixed
> >> vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
> >> So I don't see how making VID 4095 be the PVID of just standalone ports
> >> (leaving VLAN-unaware bridge ports with a different VID) would not be
> >> sufficient for the presented problem.
> >
> > The issue isn't the vlan filtering, it's the (missing) FDB isolation
> > on the ASIC.
>
> Could not we just use double tagging to overcome that limitation?

Wouldn't that break VLAN filtering on a vlan aware bridge? AFAICT
double tagging mode is global, the VLAN table is then used for
customer (port) assignment, so you can't filter on the inner/802.1Q
tag anymore. Also learning would then essentially become SVL IIUCT.
Also I think there aren't switches that support double tagging, but
don't support EAP. EAP mode might be the easier way. Assuming there
isn't a gotcha I have overlooked.

Jonas

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[Florian Fainelli]

On 5/6/2025 9:48 PM, Jonas Gorski wrote:
> On Tue, May 6, 2025 at 9:03 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>>
>>
>> On 5/6/2025 4:27 PM, Jonas Gorski wrote:
>>> On Tue, May 6, 2025 at 3:42 PM Vladimir Oltean <olteanv@gmail.com> wrote:
>>>>
>>>> / unrelated to patches /
>>>>
>>>> On Wed, Apr 30, 2025 at 10:43:40AM +0200, Jonas Gorski wrote:
>>>>>>> I have a fix/workaround for that, but as it is a bit more controversial
>>>>>>> and makes use of an unrelated feature, I decided to hold off from that
>>>>>>> and post it later.
>>>>>>
>>>>>> Can you expand on the fix/workaround you have?
>>>>>
>>>>> It's setting EAP mode to simplified on standalone ports, where it
>>>>> redirects all frames to the CPU port where there is no matching ARL
>>>>> entry for that SA and port. That should work on everything semi recent
>>>>> (including BCM63XX), and should work regardless of VLAN. It might
>>>>> cause more traffic than expected to be sent to the switch, as I'm not
>>>>> sure if multicast filtering would still work (not that I'm sure that
>>>>> it currently works lol).
>>>>>
>>>>> At first I moved standalone ports to VID 4095 for untagged traffic,
>>>>> but that only fixed the issue for untagged traffic, and you would have
>>>>> had the same issue again when using VLAN uppers. And VLAN uppers have
>>>>> the same issue on vlan aware bridges, so the above would be a more
>>>>> complete workaround.
>>>>
>>>> I don't understand the logic, can you explain "you would have had the
>>>> same issue again when using VLAN uppers"? The original issue, as you
>>>> presented it, is with bridges with vlan_filtering=0, and does not exist
>>>> with vlan_filtering=1 bridges. In the problematic mode, VLAN uppers are
>>>> not committed to hardware RX filters. And bridges with mixed
>>>> vlan_filtering values are not permitted by dsa_port_can_apply_vlan_filtering().
>>>> So I don't see how making VID 4095 be the PVID of just standalone ports
>>>> (leaving VLAN-unaware bridge ports with a different VID) would not be
>>>> sufficient for the presented problem.
>>>
>>> The issue isn't the vlan filtering, it's the (missing) FDB isolation
>>> on the ASIC.
>>
>> Could not we just use double tagging to overcome that limitation?
> 
> Wouldn't that break VLAN filtering on a vlan aware bridge? AFAICT
> double tagging mode is global, the VLAN table is then used for
> customer (port) assignment, so you can't filter on the inner/802.1Q
> tag anymore. Also learning would then essentially become SVL IIUCT.
> Also I think there aren't switches that support double tagging, but
> don't support EAP. EAP mode might be the easier way. Assuming there
> isn't a gotcha I have overlooked.

If EAP works, sure that seems like the way to go then.
-- 
Florian

Re: [PATCH net 00/11] net: dsa: b53: accumulated fixes

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Tue, 29 Apr 2025 22:16:59 +0200 you wrote:
> This patchset aims at fixing most issues observed while running the
> vlan_unaware_bridge, vlan_aware_bridge and local_termination selftests.
> 
> Most tests succeed with these patches on BCM53115, connected to a
> BCM6368.
> 
> It took me a while to figure out that a lot of tests will fail if all
> ports have the same MAC address, as the switches drop any frames with
> DA == SA. Luckily BCM63XX boards often have enough MACs allocated for
> all ports, so I just needed to assign them.
> 
> [...]

Here is the summary with links:
  - [net,01/11] net: dsa: b53: allow leaky reserved multicast
    https://git.kernel.org/netdev/net/c/5f93185a757f
  - [net,02/11] net: dsa: b53: keep CPU port always tagged again
    https://git.kernel.org/netdev/net/c/425f11d4cc9b
  - [net,03/11] net: dsa: b53: fix clearing PVID of a port
    https://git.kernel.org/netdev/net/c/f48085198104
  - [net,04/11] net: dsa: b53: fix flushing old pvid VLAN on pvid change
    https://git.kernel.org/netdev/net/c/083c6b28c0cb
  - [net,05/11] net: dsa: b53: fix VLAN ID for untagged vlan on bridge leave
    https://git.kernel.org/netdev/net/c/a1c1901c5cc8
  - [net,06/11] net: dsa: b53: always rejoin default untagged VLAN on bridge leave
    https://git.kernel.org/netdev/net/c/13b152ae4049
  - [net,07/11] net: dsa: b53: do not allow to configure VLAN 0
    https://git.kernel.org/netdev/net/c/45e9d59d3950
  - [net,08/11] net: dsa: b53: do not program vlans when vlan filtering is off
    https://git.kernel.org/netdev/net/c/f089652b6b16
  - [net,09/11] net: dsa: b53: fix toggling vlan_filtering
    https://git.kernel.org/netdev/net/c/2dc2bd571115
  - [net,10/11] net: dsa: b53: fix learning on VLAN unaware bridges
    https://git.kernel.org/netdev/net/c/9f34ad89bcf0
  - [net,11/11] net: dsa: b53: do not set learning and unicast/multicast on up
    https://git.kernel.org/netdev/net/c/2e7179c628d3

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html