• Vladimir Oltean's avatar
    net: dsa: tag_8021q: don't broadcast during setup/teardown · 724395f4
    Vladimir Oltean authored
    Currently, on my board with multiple sja1105 switches in disjoint trees
    described in commit f66a6a69 ("net: dsa: permit cross-chip bridging
    between all trees in the system"), rebooting the board triggers the
    following benign warnings:
    
    [   12.345566] sja1105 spi2.0: port 0 failed to notify tag_8021q VLAN 1088 deletion: -ENOENT
    [   12.353804] sja1105 spi2.0: port 0 failed to notify tag_8021q VLAN 2112 deletion: -ENOENT
    [   12.362019] sja1105 spi2.0: port 1 failed to notify tag_8021q VLAN 1089 deletion: -ENOENT
    [   12.370246] sja1105 spi2.0: port 1 failed to notify tag_8021q VLAN 2113 deletion: -ENOENT
    [   12.378466] sja1105 spi2.0: port 2 failed to notify tag_8021q VLAN 1090 deletion: -ENOENT
    [   12.386683] sja1105 spi2.0: port 2 failed to notify tag_8021q VLAN 2114 deletion: -ENOENT
    
    Basically switch 1 calls dsa_tag_8021q_unregister, and switch 1's TX and
    RX VLANs cannot be found on switch 2's CPU port.
    
    But why would switch 2 even attempt to delete switch 1's TX and RX
    tag_8021q VLANs from its CPU port? Well, because we use dsa_broadcast,
    and it is supposed that it had added those VLANs in the first place
    (because in dsa_port_tag_8021q_vlan_match, all CPU ports match
    regardless of their tree index or switch index).
    
    The two trees probe asynchronously, and when switch 1 probed, it called
    dsa_broadcast which did not notify the tree of switch 2, because that
    didn't probe yet. But during unbind, switch 2's tree _is_ probed, so it
    _is_ notified of the deletion.
    
    Before jumping to introduce a synchronization mechanism between the
    probing across disjoint switch trees, let's take a step back and see
    whether we _need_ to do that in the first place.
    
    The RX and TX VLANs of switch 1 would be needed on switch 2's CPU port
    only if switch 1 and 2 were part of a cross-chip bridge. And
    dsa_tag_8021q_bridge_join takes care precisely of that (but if probing
    was synchronous, the bridge_join would just end up bumping the VLANs'
    refcount, because they are already installed by the setup path).
    
    Since by the time the ports are bridged, all DSA trees are already set
    up, and we don't need the tag_8021q VLANs of one switch installed on the
    other switches during probe time, the answer is that we don't need to
    fix the synchronization issue.
    
    So make the setup and teardown code paths call dsa_port_notify, which
    notifies only the local tree, and the bridge code paths call
    dsa_broadcast, which let the other trees know as well.
    Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    724395f4
port.c 32.2 KB