04 Mar, 2019
2 commits
-
We were skipping the prepare phase which causes some problems with at
least a couple of drivers:- mv88e6xxx chooses to skip programming VID = 0 with -EOPNOTSUPP in
the prepare phase, but we would still try to force this VID since we
would only call the commit phase and so we would get the driver to
return -EINVAL instead- qca8k does not currently have a port_vlan_add() callback implemented,
yet we would try to call that unconditionally leading to a NPDFix both issues by conforming to the current model doing a
prepare/commit phase, this makes us consistent throughout the code and
assumptions.Reported-by: Heiner Kallweit
Reported-by: Michal Vokáč
Fixes: 061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation")
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller -
KSZ9893 switch is similar to KSZ9477 switch except the ingress tail tag
has 1 byte instead of 2 bytes. The size of the portmap is smaller and
so the override and lookup bits are also moved.Signed-off-by: Tristram Ha
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
03 Mar, 2019
1 commit
28 Feb, 2019
2 commits
-
Now that we have converted all possible callers to using a switchdev
notifier for attributes we do not have a need for implementing
switchdev_ops anymore, and this can be removed from all drivers the
net_device structure.Signed-off-by: Florian Fainelli
Reviewed-by: Ido Schimmel
Signed-off-by: David S. Miller -
Following patches will change the way we communicate setting a port's
attribute and use notifiers towards that goal.Prepare DSA to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET from both atomic and process context and use a
small helper to translate the event notifier into something that
dsa_slave_port_attr_set() can process.Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
27 Feb, 2019
1 commit
-
Being able to build devlink as a module causes growing pains.
First all drivers had to add a meta dependency to make sure
they are not built in when devlink is built as a module. Now
we are struggling to invoke ethtool compat code reliably.Make devlink code built-in, users can still not build it at
all but the dynamically loadable module option is removed.Signed-off-by: Jakub Kicinski
Reviewed-by: Florian Fainelli
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller
26 Feb, 2019
1 commit
-
The call to of_parse_phandle returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.Detected by coccinelle with the following warnings:
./net/dsa/port.c:294:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 284, but without a corresponding object release within this function.
./net/dsa/dsa2.c:627:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:630:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:636:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.
./net/dsa/dsa2.c:639:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 618, but without a corresponding object release within this function.Signed-off-by: Wen Yang
Reviewed-by: Vivien Didelot
Cc: Andrew Lunn
Cc: Vivien Didelot
Cc: Florian Fainelli
Cc: "David S. Miller"
Cc: Vivien Didelot
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller
25 Feb, 2019
2 commits
-
No current DSA driver makes use of the phydev parameter passed to the
disable_port call. Remove it.Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller -
Three conflicts, one of which, for marvell10g.c is non-trivial and
requires some follow-up from Heiner or someone else.The issue is that Heiner converted the marvell10g driver over to
use the generic c45 code as much as possible.However, in 'net' a bug fix appeared which makes sure that a new
local mask (MDIO_AN_10GBT_CTRL_ADV_NBT_MASK) with value 0x01e0
is cleared.Signed-off-by: David S. Miller
23 Feb, 2019
2 commits
-
In order to properly support VLAN filtering being enabled/disabled on a
bridge, while having other ports being non bridge port members, we need
to support the ndo_vlan_rx_{add,kill}_vid callbacks in order to make
sure the non-bridge ports can continue receiving VLAN tags, even when
the switch is globally configured to do ingress/egress VID checking.Since we can call dsa_port_vlan_{add,del} with a bridge_dev pointer
NULL, we now need to check that in these two functions.We specifically deal with two possibly problematic cases:
- creating a bridge VLAN entry while there is an existing VLAN device
claiming that same VID- creating a VLAN device while there is an existing bridge VLAN entry
with that VIDThose are both resolved with returning -EBUSY back to user-space.
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller -
VLAN devices on top of a DSA network device which is already part of a
bridge and with said bridge being VLAN aware should not be allowed to be
enslaved into that bridge. For one, this duplicates functionality
offered by the VLAN aware bridge which supports tagged and untagged VLAN
frames processing and it would make things needlessly complex to e.g.:
propagate FDB/MDB accordingly.Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
22 Feb, 2019
5 commits
-
With the bridge no longer calling switchdev_port_attr_get() to obtain
the supported bridge port flags from a driver but instead trying to set
the bridge port flags directly and relying on driver to reject
unsupported configurations, we can effectively get rid of
switchdev_port_attr_get() entirely since this was the only place where
it was called.Signed-off-by: Florian Fainelli
Reviewed-by: Ido Schimmel
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
Now that we have converted the bridge code and the drivers to check for
bridge port(s) flags at the time we try to set them, there is no need
for a get() -> set() sequence anymore and
SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused.Reviewed-by: Ido Schimmel
Signed-off-by: Florian Fainelli
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
add support for a function that processes the
SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS and
SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attributes and returns not
supported for any flag set, since DSA does not currently support
toggling those bridge port attributes (yet).Signed-off-by: Florian Fainelli
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
Switches work by learning the MAC address for each attached station by
monitoring traffic from each station. When a station sends a packet,
the switch records which port the MAC address is connected to.With IPv4 networking, before communication commences with a neighbour,
an ARP packet is broadcasted to all stations asking for the MAC address
corresponding with the IPv4. The desired station responds with an ARP
reply, and the ARP reply causes the switch to learn which port the
station is connected to.With IPv6 networking, the situation is rather different. Rather than
broadcasting ARP packets, a "neighbour solicitation" is multicasted
rather than broadcasted. This multicast needs to reach the intended
station in order for the neighbour to be discovered.Once a neighbour has been discovered, and entered into the sending
stations neighbour cache, communication can restart at a point later
without sending a new neighbour solicitation, even if the entry in
the neighbour cache is marked as stale. This can be after the MAC
address has expired from the forwarding cache of the DSA switch -
when that occurs, there is a long pause in communication.Our DSA implementation for mv88e6xxx switches disables flooding of
multicast and unicast frames for bridged ports. As per the above
description, this is fine for IPv4 networking, since the broadcasted
ARP queries will be sent to and received by all stations on the same
network. However, this breaks IPv6 very badly - blocking neighbour
solicitations and later causing connections to stall.The defaults that the Linux bridge code expect from bridges are for
unknown unicast and unknown multicast frames to be flooded to all ports
on the bridge, which is at odds to the defaults adopted by our DSA
implementation for mv88e6xxx switches.This commit enables by default flooding of both unknown unicast and
unknown multicast frames whenever a port is added to a bridge, and
disables the flooding when a port leaves the bridge. This means that
mv88e6xxx DSA switches now behave as per the bridge(8) man page, and
IPv6 works flawlessly through such a switch.Reviewed-by: Florian Fainelli
Reviewed-by: Vivien Didelot
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
The Linux bridge implementation allows various properties of the bridge
to be controlled, such as flooding unknown unicast and multicast frames.
This patch adds the necessary DSA infrastructure to allow the Linux
bridge support to control these properties for DSA switches.Reviewed-by: Vivien Didelot
Signed-off-by: Russell King
[florian: Add missing dp and ds variables declaration to fix build]
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
21 Feb, 2019
1 commit
-
When a DSA port is added to a bridge and brought up, the resulting STP
state programmed into the hardware depends on the order that these
operations are performed. However, the Linux bridge code believes that
the port is in disabled mode.If the DSA port is first added to a bridge and then brought up, it will
be in blocking mode. If it is brought up and then added to the bridge,
it will be in disabled mode.This difference is caused by DSA always setting the STP mode in
dsa_port_enable() whether or not this port is part of a bridge. Since
bridge always sets the STP state when the port is added, brought up or
taken down, it is unnecessary for us to manipulate the STP state.Apparently, this code was copied from Rocker, and the very next day a
similar fix for Rocker was merged but was not propagated to DSA. See
e47172ab7e41 ("rocker: put port in FORWADING state after leaving bridge")Fixes: b73adef67765 ("net: dsa: integrate with SWITCHDEV for HW bridging")
Signed-off-by: Russell King
Reviewed-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
19 Feb, 2019
1 commit
-
RPS not work for DSA devices since the 'skb_get_hash'
will always get the invalid hash for dsa tagged packets."[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
introduced the flow_dissect callback to get the right hash for
MTK tagged packet. Tag_dsa and tag_edsa also need to implement
the callback.Signed-off-by: Rundong Ge
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
12 Feb, 2019
1 commit
-
The flag offload_fwd_mark is set as the switch can forward frames by
itself.This can be considered a fix to a problem introduced in commit
c2e866911e254067 where the port membership are not set in sync. The flag
offload_fwd_mark just needs to be set in tag_ksz.c to prevent the software
bridge from forwarding duplicate multicast frames.Fixes: c2e866911e254067 ("microchip: break KSZ9477 DSA driver into two files")
Signed-off-by: Tristram Ha
Signed-off-by: David S. Miller
09 Feb, 2019
2 commits
-
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:struct foo {
int stuff;
struct boo entry[];
};size = sizeof(struct foo) + count * sizeof(struct boo);
instance = alloc(size, GFP_KERNEL)Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:instance = alloc(struct_size(instance, entry, count), GFP_KERNEL)
Notice that, in this case, variable size is not necessary, hence it is
removed.This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Vivien Didelot
Signed-off-by: David S. Miller -
An ipvlan bug fix in 'net' conflicted with the abstraction away
of the IPV6 specific support in 'net-next'.Similarly, a bug fix for mlx5 in 'net' conflicted with the flow
action conversion in 'net-next'.Signed-off-by: David S. Miller
07 Feb, 2019
2 commits
-
DSA implements SWITCHDEV_ATTR_ID_PORT_PARENT_ID and we want to get rid
of switchdev_ops eventually, ease that migration by implementing a
ndo_get_port_parent_id() function which returns what
switchdev_port_attr_get() would do.Acked-by: Jiri Pirko
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller -
This function can't succeed if dp->pl is NULL. It will Oops inside the
call to return phylink_ethtool_get_eee(dp->pl, e);Fixes: 1be52e97ed3e ("dsa: slave: eee: Allow ports to use phylink")
Signed-off-by: Dan Carpenter
Reviewed-by: Florian Fainelli
Reviewed-by: Vivien Didelot
Signed-off-by: David S. Miller
05 Feb, 2019
2 commits
-
Creating a macvtap on a DSA-backed interface results in the following
splat when lockdep is enabled:[ 19.638080] IPv6: ADDRCONF(NETDEV_CHANGE): lan0: link becomes ready
[ 23.041198] device lan0 entered promiscuous mode
[ 23.043445] device eth0 entered promiscuous mode
[ 23.049255]
[ 23.049557] ============================================
[ 23.055021] WARNING: possible recursive locking detected
[ 23.060490] 5.0.0-rc3-00013-g56c857a1b8d3 #118 Not tainted
[ 23.066132] --------------------------------------------
[ 23.071598] ip/2861 is trying to acquire lock:
[ 23.076171] 00000000f61990cb (_xmit_ETHER){+...}, at: dev_set_rx_mode+0x1c/0x38
[ 23.083693]
[ 23.083693] but task is already holding lock:
[ 23.089696] 00000000ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70
[ 23.096774]
[ 23.096774] other info that might help us debug this:
[ 23.103494] Possible unsafe locking scenario:
[ 23.103494]
[ 23.109584] CPU0
[ 23.112093] ----
[ 23.114601] lock(_xmit_ETHER);
[ 23.117917] lock(_xmit_ETHER);
[ 23.121233]
[ 23.121233] *** DEADLOCK ***
[ 23.121233]
[ 23.127325] May be due to missing lock nesting notation
[ 23.127325]
[ 23.134315] 2 locks held by ip/2861:
[ 23.137987] #0: 000000003b766c72 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x338/0x4e0
[ 23.146231] #1: 00000000ecf0c3b4 (_xmit_ETHER){+...}, at: dev_uc_add+0x24/0x70
[ 23.153757]
[ 23.153757] stack backtrace:
[ 23.158243] CPU: 0 PID: 2861 Comm: ip Not tainted 5.0.0-rc3-00013-g56c857a1b8d3 #118
[ 23.166212] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
[ 23.172843] Call trace:
[ 23.175358] dump_backtrace+0x0/0x188
[ 23.179116] show_stack+0x14/0x20
[ 23.182524] dump_stack+0xb4/0xec
[ 23.185928] __lock_acquire+0x123c/0x1860
[ 23.190048] lock_acquire+0xc8/0x248
[ 23.193724] _raw_spin_lock_bh+0x40/0x58
[ 23.197755] dev_set_rx_mode+0x1c/0x38
[ 23.201607] dev_set_promiscuity+0x3c/0x50
[ 23.205820] dsa_slave_change_rx_flags+0x5c/0x70
[ 23.210567] __dev_set_promiscuity+0x148/0x1e0
[ 23.215136] __dev_set_rx_mode+0x74/0x98
[ 23.219167] dev_uc_add+0x54/0x70
[ 23.222575] macvlan_open+0x170/0x1d0
[ 23.226336] __dev_open+0xe0/0x160
[ 23.229830] __dev_change_flags+0x16c/0x1b8
[ 23.234132] dev_change_flags+0x20/0x60
[ 23.238074] do_setlink+0x2d0/0xc50
[ 23.241658] __rtnl_newlink+0x5f8/0x6e8
[ 23.245601] rtnl_newlink+0x50/0x78
[ 23.249184] rtnetlink_rcv_msg+0x360/0x4e0
[ 23.253397] netlink_rcv_skb+0xe8/0x130
[ 23.257338] rtnetlink_rcv+0x14/0x20
[ 23.261012] netlink_unicast+0x190/0x210
[ 23.265043] netlink_sendmsg+0x288/0x350
[ 23.269075] sock_sendmsg+0x18/0x30
[ 23.272659] ___sys_sendmsg+0x29c/0x2c8
[ 23.276602] __sys_sendmsg+0x60/0xb8
[ 23.280276] __arm64_sys_sendmsg+0x1c/0x28
[ 23.284488] el0_svc_common+0xd8/0x138
[ 23.288340] el0_svc_handler+0x24/0x80
[ 23.292192] el0_svc+0x8/0xcThis looks fairly harmless (no actual deadlock occurs), and is
fixed in a similar way to c6894dec8ea9 ("bridge: fix lockdep
addr_list_lock false positive splat") by putting the addr_list_lock
in its own lockdep class.Signed-off-by: Marc Zyngier
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
The unbalance of master's promiscuity or allmulti will happen after ifdown
and ifup a slave interface which is in a bridge.When we ifdown a slave interface , both the 'dsa_slave_close' and
'dsa_slave_change_rx_flags' will clear the master's flags. The flags
of master will be decrease twice.
In the other hand, if we ifup the slave interface again, since the
slave's flags were cleared the 'dsa_slave_open' won't set the master's
flag, only 'dsa_slave_change_rx_flags' that triggered by 'br_add_if'
will set the master's flags. The flags of master is increase once.Only propagating flag changes when a slave interface is up makes
sure this does not happen. The 'vlan_dev_change_rx_flags' had the
same problem and was fixed, and changes here follows that fix.Fixes: 91da11f870f0 ("net: Distributed Switch Architecture protocol support")
Signed-off-by: Rundong Ge
Signed-off-by: David S. Miller
18 Jan, 2019
2 commits
-
A follow-up patch will enable vetoing of FDB entries. Make it possible
to communicate details of why an FDB entry is not acceptable back to the
user.Signed-off-by: Petr Machata
Signed-off-by: David S. Miller -
Drivers may not be able to support certain FDB entries, and an error
code is insufficient to give clear hints as to the reasons of rejection.In order to make it possible to communicate the rejection reason, extend
ndo_fdb_add() with an extack argument. Adapt the existing
implementations of ndo_fdb_add() to take the parameter (and ignore it).
Pass the extack parameter when invoking ndo_fdb_add() from rtnl_fdb_add().Signed-off-by: Petr Machata
Signed-off-by: David S. Miller
17 Jan, 2019
1 commit
-
There is not currently way to infer the port number through sysfs that
is being used as the CPU port number. Overlay a ndo_get_phys_port_name()
operation onto the DSA master network device in order to retrieve that
information.Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
17 Dec, 2018
3 commits
-
In case the destination address is link local, add override bit into the
switch tag to let such a packet through the switch even if the port is
blocked.Signed-off-by: Marek Vasut
Cc: Tristram Ha
Cc: Vivien Didelot
Cc: Woojung Huh
Cc: David S. Miller
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Factor out common code from the tag_ksz , so that the code can be used
with other KSZ family switches which use differenly sized tags.Signed-off-by: Tristram Ha
Signed-off-by: Marek Vasut
Cc: Vivien Didelot
Cc: Woojung Huh
Cc: David S. Miller
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Rename the tag Kconfig option and related macros in preparation for
addition of new KSZ family switches with different tag formats.Signed-off-by: Tristram Ha
Signed-off-by: Marek Vasut
Cc: Vivien Didelot
Cc: Woojung Huh
Cc: David S. Miller
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
10 Dec, 2018
1 commit
-
Several conflicts, seemingly all over the place.
I used Stephen Rothwell's sample resolutions for many of these, if not
just to double check my own work, so definitely the credit largely
goes to him.The NFP conflict consisted of a bug fix (moving operations
past the rhashtable operation) while chaning the initial
argument in the function call in the moved code.The net/dsa/master.c conflict had to do with a bug fix intermixing of
making dsa_master_set_mtu() static with the fixing of the tagging
attribute location.cls_flower had a conflict because the dup reject fix from Or
overlapped with the addition of port range classifiction.__set_phy_supported()'s conflict was relatively easy to resolve
because Andrew fixed it in both trees, so it was just a matter
of taking the net-next copy. Or at least I think it was :-)Joe Stringer's fix to the handling of netns id 0 in bpf_sk_lookup()
intermixed with changes on how the sdif and caller_net are calculated
in these code paths in net-next.The remaining BPF conflicts were largely about the addition of the
__bpf_md_ptr stuff in 'net' overlapping with adjustments and additions
to the relevant data structure where the MD pointer macros are used.Signed-off-by: David S. Miller
09 Dec, 2018
2 commits
-
Add the missing static keyword.
Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller -
A previous change tries to set the MTU on the master device to take
into account the DSA overheads. This patch tries to reset the master
device back to the default MTU.Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller
07 Dec, 2018
2 commits
-
DSA tagging of frames sent over the master interface to the switch
increases the size of the frame. Such frames can then be bigger than
the normal MTU of the master interface, and it may drop them. Use the
overhead information from the tagger to set the MTU of the master
device to include this overhead.Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller -
Each DSA tag protocol needs to add additional headers to the Ethernet
frame in order to direct it towards a specific switch egress port. It
must also remove the head from a frame received from a
switch. Indicate the maximum size of these headers in the tag protocol
ops structure, so the core can take these overheads into account.Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller
01 Dec, 2018
1 commit
-
While introducing the DSA tagging protocol attribute, it was added to the DSA
slave network devices, but those actually see untagged traffic (that is their
whole purpose). Correct this mistake by putting the tagging sysfs attribute
under the DSA master network device where this is the information that we need.While at it, also correct the sysfs documentation mistake that missed the
"dsa/" directory component of the attribute.Fixes: 98cdb4807123 ("net: dsa: Expose tagging protocol to user-space")
Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
24 Nov, 2018
3 commits
-
Due to an explicit check in rocker_world_port_obj_vlan_add(),
dsa_slave_switchdev_event() resp. port_switchdev_event(), VLAN objects
that are added to a device that is not a front-panel port device are
ignored. Therefore this check is immaterial.Signed-off-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller -
Drop switchdev_ops.switchdev_port_obj_add and _del. Drop the uses of
this field from all clients, which were migrated to use switchdev
notification in the previous patches.Add a new function switchdev_port_obj_notify() that sends the switchdev
notifications SWITCHDEV_PORT_OBJ_ADD and _DEL.Update switchdev_port_obj_del_now() to dispatch to this new function.
Drop __switchdev_port_obj_add() and update switchdev_port_obj_add()
likewise.Signed-off-by: Petr Machata
Reviewed-by: Ido Schimmel
Signed-off-by: David S. Miller -
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.DSA currently doesn't support any other uppers 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 dsa_port_vlan_add(). It
is therefore safe to assume that the only interesting case is that the
notification is on a front-panel port netdevice. Therefore keep the
filtering by dsa_slave_dev_check() in place.To handle SWITCHDEV_PORT_OBJ_ADD and _DEL, subscribe to the blocking
notifier chain. Dispatch to rocker_port_obj_add() resp. _del() to
maintain the behavior that the switchdev operation based code currently
has.Signed-off-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: David S. Miller