• Vladimir Oltean's avatar
    net: dsa: make tagging protocols connect to individual switches from a tree · 7f297314
    Vladimir Oltean authored
    On the NXP Bluebox 3 board which uses a multi-switch setup with sja1105,
    the mechanism through which the tagger connects to the switch tree is
    broken, due to improper DSA code design. At the time when tag_ops->connect()
    is called in dsa_port_parse_cpu(), DSA hasn't finished "touching" all
    the ports, so it doesn't know how large the tree is and how many ports
    it has. It has just seen the first CPU port by this time. As a result,
    this function will call the tagger's ->connect method too early, and the
    tagger will connect only to the first switch from the tree.
    
    This could be perhaps addressed a bit more simply by just moving the
    tag_ops->connect(dst) call a bit later (for example in dsa_tree_setup),
    but there is already a design inconsistency at present: on the switch
    side, the notification is on a per-switch basis, but on the tagger side,
    it is on a per-tree basis. Furthermore, the persistent storage itself is
    per switch (ds->tagger_data). And the tagger connect and disconnect
    procedures (at least the ones that exist currently) could see a fair bit
    of simplification if they didn't have to iterate through the switches of
    a tree.
    
    To fix the issue, this change transforms tag_ops->connect(dst) into
    tag_ops->connect(ds) and moves it somewhere where we already iterate
    over all switches of a tree. That is in dsa_switch_setup_tag_protocol(),
    which is a good placement because we already have there the connection
    call to the switch side of things.
    
    As for the dsa_tree_bind_tag_proto() method (called from the code path
    that changes the tag protocol), things are a bit more complicated
    because we receive the tree as argument, yet when we unwind on errors,
    it would be nice to not call tag_ops->disconnect(ds) where we didn't
    previously call tag_ops->connect(ds). We didn't have this problem before
    because the tag_ops connection operations passed the entire dst before,
    and this is more fine grained now. To solve the error rewind case using
    the new API, we have to create yet one more cross-chip notifier for
    disconnection, and stay connected with the old tag protocol to all the
    switches in the tree until we've succeeded to connect with the new one
    as well. So if something fails half way, the whole tree is still
    connected to the old tagger. But there may still be leaks if the tagger
    fails to connect to the 2nd out of 3 switches in a tree: somebody needs
    to tell the tagger to disconnect from the first switch. Nothing comes
    for free, and this was previously handled privately by the tagging
    protocol driver before, but now we need to emit a disconnect cross-chip
    notifier for that, because DSA has to take care of the unwind path. We
    assume that the tagging protocol has connected to a switch if it has set
    ds->tagger_data to something, otherwise we avoid calling its
    disconnection method in the error rewind path.
    
    The rest of the changes are in the tagging protocol drivers, and have to
    do with the replacement of dst with ds. The iteration is removed and the
    error unwind path is simplified, as mentioned above.
    Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    7f297314
dsa2.c 38.8 KB