Merge branch 'dsa-add-fabric-notifier'
authorDavid S. Miller <davem@davemloft.net>
Mon, 6 Feb 2017 21:53:30 +0000 (16:53 -0500)
committerDavid S. Miller <davem@davemloft.net>
Mon, 6 Feb 2017 21:53:30 +0000 (16:53 -0500)
commit9172d2a026f95f217da81610037608996d3f6a3f
tree07ed46ceedeb980d62da34ae26e3aac5f8af7dfb
parent321fa4ffd94e333657e54037d2511c862ec92f6f
parent04d3a4c6af52a58370795bc9f70dc15f51f8bb84
Merge branch 'dsa-add-fabric-notifier'

Vivien Didelot says:

====================
net: dsa: add fabric notifier

When a switch fabric is composed of multiple switch chips, these chips
must be programmed accordingly when an event occurred on one of them.

Examples of such event include hardware bridging: when a Linux bridge
spans interconnected chips, they must be programmed to allow external
ports to ingress frames on their internal ports.

Another example is cross-chip hardware VLANs. Switch chips in-between
interconnected bridge ports must also configure a given VLAN to allow
packets to pass through them.

In order to support that, this patchset introduces a non-intrusive
notifier mechanism. It adds a notifier head in every DSA switch tree
(the said fabric), and a notifier block in every DSA switch chip.

When an even occurs, it is chained to all notifiers of the fabric.
Switch chips can react accordingly if they are cross-chip capable.

On a dynamic debug enabled system, bridging a port in a multi-chip
fabric will print something like this (ZII Rev B board):

    # brctl addif br0 lan3
    mv88e6085 0.1:00: crosschip DSA port 1.0 bridged to br0
    mv88e6085 0.4:00: crosschip DSA port 1.0 bridged to br0
    # brctl delif br0 lan3
    mv88e6085 0.1:00: crosschip DSA port 1.0 unbridged from br0
    mv88e6085 0.4:00: crosschip DSA port 1.0 unbridged from br0

Currently only bridging events are added. A patchset introducing support
for cross-chip hardware bridging configuration in mv88e6xxx will follow
right after. Then events for switchdev operations are next on the line.

We should note that non-switchdev events do not support rolling-back
switch-wide operations. We'll have to work on closer integration with
switchdev for that, like introducing new attributes or objects, to
benefit from the prepare and commit phases.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>