mirror of https://github.com/torvalds/linux.git
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:
|
||
|---|---|---|
| .. | ||
| fdma | ||
| lan865x | ||
| lan966x | ||
| sparx5 | ||
| vcap | ||
| Kconfig | ||
| Makefile | ||
| enc28j60.c | ||
| enc28j60_hw.h | ||
| encx24j600-regmap.c | ||
| encx24j600.c | ||
| encx24j600_hw.h | ||
| lan743x_ethtool.c | ||
| lan743x_ethtool.h | ||
| lan743x_main.c | ||
| lan743x_main.h | ||
| lan743x_ptp.c | ||
| lan743x_ptp.h | ||