From: Jonas Gorski <jonas.gorski@gmail.com>
To: Florian Fainelli <florian.fainelli@broadcom.com>,
Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Russell King <linux@armlinux.org.uk>,
Kurt Kanzenbach <kurt@linutronix.de>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH net 00/11] net: dsa: b53: accumulated fixes
Date: Tue, 29 Apr 2025 22:16:59 +0200 [thread overview]
Message-ID: <20250429201710.330937-1-jonas.gorski@gmail.com> (raw)
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
next reply other threads:[~2025-04-29 20:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 20:16 Jonas Gorski [this message]
2025-04-29 20:17 ` [PATCH net 01/11] net: dsa: b53: allow leaky reserved multicast Jonas Gorski
2025-04-29 20:17 ` [PATCH net 02/11] net: dsa: b53: keep CPU port always tagged again Jonas Gorski
2025-04-29 20:17 ` [PATCH net 03/11] net: dsa: b53: fix clearing PVID of a port Jonas Gorski
2025-04-29 20:17 ` [PATCH net 04/11] net: dsa: b53: fix flushing old pvid VLAN on pvid change Jonas Gorski
2025-04-30 8:03 ` Florian Fainelli
2025-04-30 9:00 ` Jonas Gorski
2025-04-29 20:17 ` [PATCH net 05/11] net: dsa: b53: fix VLAN ID for untagged vlan on bridge leave Jonas Gorski
2025-04-29 20:17 ` [PATCH net 06/11] net: dsa: b53: always rejoin default untagged VLAN " Jonas Gorski
2025-04-29 20:17 ` [PATCH net 07/11] net: dsa: b53: do not allow to configure VLAN 0 Jonas Gorski
2025-04-29 20:17 ` [PATCH net 08/11] net: dsa: b53: do not program vlans when vlan filtering is off Jonas Gorski
2025-04-29 20:17 ` [PATCH net 09/11] net: dsa: b53: fix toggling vlan_filtering Jonas Gorski
2025-05-06 7:51 ` Paolo Abeni
2025-05-06 7:55 ` Florian Fainelli
2025-04-29 20:17 ` [PATCH net 10/11] net: dsa: b53: fix learning on VLAN unaware bridges Jonas Gorski
2025-04-29 20:17 ` [PATCH net 11/11] net: dsa: b53: do not set learning and unicast/multicast on up Jonas Gorski
2025-04-30 8:07 ` [PATCH net 00/11] net: dsa: b53: accumulated fixes Florian Fainelli
2025-04-30 8:43 ` Jonas Gorski
2025-05-06 13:42 ` Vladimir Oltean
2025-05-06 14:27 ` Jonas Gorski
2025-05-06 19:03 ` Florian Fainelli
2025-05-06 19:48 ` Jonas Gorski
2025-05-07 7:30 ` Florian Fainelli
2025-05-06 13:08 ` Florian Fainelli
2025-05-08 2:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250429201710.330937-1-jonas.gorski@gmail.com \
--to=jonas.gorski@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=florian.fainelli@broadcom.com \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox