diff options
author | Vladimir Oltean <vladimir.oltean@nxp.com> | 2021-03-23 02:51:42 +0300 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2021-03-24 00:49:05 +0300 |
commit | c0e715bbd50e57319f76d0b757dc282893f2d476 (patch) | |
tree | d6b9da556666db7f8fa9cef38ecc42dca88dea42 /samples | |
parent | 65d2dbb300197839eafc4171cfeb57a14c452724 (diff) | |
download | linux-c0e715bbd50e57319f76d0b757dc282893f2d476.tar.xz |
net: bridge: add helper for retrieving the current bridge port STP state
It may happen that we have the following topology with DSA or any other
switchdev driver with LAG offload:
ip link add br0 type bridge stp_state 1
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
ip link set swp1 master bond0
STP decides that it should put bond0 into the BLOCKING state, and
that's that. The ports that are actively listening for the switchdev
port attributes emitted for the bond0 bridge port (because they are
offloading it) and have the honor of seeing that switchdev port
attribute can react to it, so we can program swp0 and swp1 into the
BLOCKING state.
But if then we do:
ip link set swp2 master bond0
then as far as the bridge is concerned, nothing has changed: it still
has one bridge port. But this new bridge port will not see any STP state
change notification and will remain FORWARDING, which is how the
standalone code leaves it in.
We need a function in the bridge driver which retrieves the current STP
state, such that drivers can synchronize to it when they may have missed
switchdev events.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com>
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'samples')
0 files changed, 0 insertions, 0 deletions