diff options
| author | Jonas Gorski <jonas.gorski@gmail.com> | 2025-04-29 22:17:10 +0200 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2025-05-07 19:30:35 -0700 |
| commit | 2e7179c628d3cb9aee75e412473813b099e11ed4 (patch) | |
| tree | 95a0a3862c0e940d25aaa5dfaee3bf96b380efe5 /scripts/generate_rust_analyzer.py | |
| parent | 9f34ad89bcf0e6df6f8b01f1bdab211493fc66d1 (diff) | |
| download | linux-2e7179c628d3cb9aee75e412473813b099e11ed4.tar.gz linux-2e7179c628d3cb9aee75e412473813b099e11ed4.tar.bz2 linux-2e7179c628d3cb9aee75e412473813b099e11ed4.zip | |
net: dsa: b53: do not set learning and unicast/multicast on up
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>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20250429201710.330937-12-jonas.gorski@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'scripts/generate_rust_analyzer.py')
0 files changed, 0 insertions, 0 deletions