summaryrefslogtreecommitdiffstats
path: root/lib/atomic64.c
diff options
context:
space:
mode:
authorPetr Machata <petrm@mellanox.com>2018-11-22 23:29:30 +0000
committerDavid S. Miller <davem@davemloft.net>2018-11-23 18:02:24 -0800
commita39b888863afef5d43d6262d14b2f153ccda3151 (patch)
treed805e3998f8d55ad540a36572694bd1760ba174e /lib/atomic64.c
parentbb896805611fae33a67edb20820147b8a9ca68a5 (diff)
downloadlinux-a39b888863afef5d43d6262d14b2f153ccda3151.tar.gz
linux-a39b888863afef5d43d6262d14b2f153ccda3151.tar.bz2
linux-a39b888863afef5d43d6262d14b2f153ccda3151.zip
staging: fsl-dpaa2: ethsw: Handle SWITCHDEV_PORT_OBJ_ADD/_DEL
Following patches will change the way of distributing port object changes from a switchdev operation to a switchdev notifier. The switchdev code currently recursively descends through layers of lower devices, eventually calling the op on a front-panel port device. The notifier will instead be sent referencing the bridge port device, which may be a stacking device that's one of front-panel ports uppers, or a completely unrelated device. ethsw currently doesn't support any uppers other than bridge. SWITCHDEV_OBJ_ID_HOST_MDB and _PORT_MDB objects are always notified on the bridge port device. Thus the only case that a stacked device could be validly referenced by port object notifications are bridge notifications for VLAN objects added to the bridge itself. But the driver explicitly rejects such notifications in port_vlans_add(). It is therefore safe to assume that the only interesting case is that the notification is on a front-panel port netdevice. To handle SWITCHDEV_PORT_OBJ_ADD and _DEL, subscribe to the blocking notifier chain. Dispatch to swdev_port_obj_add() resp. _del() to maintain the behavior that the switchdev operation based code currently has. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'lib/atomic64.c')
0 files changed, 0 insertions, 0 deletions