net: sparx5/lan969x: fix flooding configuration on bridge join/leave
The sparx5 driver programs UC/MC/BC flooding in sparx5_update_fwd() by
unconditionally applying bridge_fwd_mask to all flood PGIDs. Any bridge
topology change that triggers sparx5_update_fwd() (for example enslaving
another port) therefore reinstalls flooding in hardware for already
bridged ports, regardless of their per-port flood flags.
This results in clobbering of the flood masks, and desynchronization
between software and hardware: the bridge still reports “flood off” for
the port, but hardware has flooding enabled due to unconditional PGID
reprogramming.
Steps to reproduce:
$ ip link add br0 type bridge
$ ip link set br0 up
$ ip link set eth0 master br0
$ ip link set eth0 up
$ bridge link set dev eth0 flood off
$ ip link set eth1 master br0
$ ip link set eth1 up
At this point, flooding is silently re-enabled for eth0. Software still
shows “flood off” for eth0, but hardware has flooding enabled.
To fix this, flooding is now set explicitly during bridge join/leave,
through sparx5_port_attr_bridge_flags():
On bridge join, UC/MC/BC flooding is enabled by default.
On bridge leave, UC/MC/BC flooding is disabled.
sparx5_update_fwd() no longer touches the flood PGIDs, clobbering
the flood masks, and desynchronizing software and hardware.
Initialization of the flooding PGIDs have been moved to
sparx5_start(). This is required as flooding PGIDs defaults to
0x3fffffff in hardware and the initialization was previously handled
in sparx5_update_fwd(), which was removed.
With this change, user-configured flooding flags persist across bridge
updates and are no longer overridden by sparx5_update_fwd().
Fixes: d6fce5141929 ("net: sparx5: add switching support")
Signed-off-by: Daniel Machon <daniel.machon@microchip.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20251003-fix-flood-fwd-v1-1-48eb478b2904@microchip.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
gentwo / linux / .git / commit