05 Oct, 2020
1 commit
-
A driver may refuse to enable VLAN filtering for any reason beyond what
the DSA framework cares about, such as:
- having tc-flower rules that rely on the switch being VLAN-aware
- the particular switch does not support VLAN, even if the driver does
(the DSA framework just checks for the presence of the .port_vlan_add
and .port_vlan_del pointers)
- simply not supporting this configuration to be toggled at runtimeCurrently, when a driver rejects a configuration it cannot support, it
does this from the commit phase, which triggers various warnings in
switchdev.So propagate the prepare phase to drivers, to give them the ability to
refuse invalid configurations cleanly and avoid the warnings.Since we need to modify all function prototypes and check for the
prepare phase from within the drivers, take that opportunity and move
the existing driver restrictions within the prepare phase where that is
possible and easy.Cc: Florian Fainelli
Cc: Martin Blumenstingl
Cc: Hauke Mehrtens
Cc: Woojung Huh
Cc: Microchip Linux Driver Support
Cc: Sean Wang
Cc: Landen Chao
Cc: Andrew Lunn
Cc: Vivien Didelot
Cc: Jonathan McDowell
Cc: Linus Walleij
Cc: Alexandre Belloni
Cc: Claudiu Manoil
Signed-off-by: Vladimir Oltean
Signed-off-by: David S. Miller
21 Sep, 2020
1 commit
-
This is checking for the following order of operations, and makes sure
to deny that configuration:ip link add link swp2 name swp2.100 type vlan id 100
ip link add br0 type bridge vlan_filtering 1
ip link set swp2 master br0
bridge vlan add dev swp2 vid 100Instead of using vlan_for_each(), which looks at the VLAN filters
installed with vlan_vid_add(), just track the 8021q uppers. This has the
advantage of freeing up the vlan_vid_add() call for actual VLAN
filtering.There is another change in this patch. The check is moved in slave.c,
from switch.c. I don't think it makes sense to have this 8021q upper
check for each switch port that gets notified of that VLAN addition
(these include DSA links and CPU ports, we know those can't have 8021q
uppers because they don't have a net_device registered for them), so
just do it in slave.c, for that one slave interface.Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
11 May, 2020
1 commit
-
One way of utilizing DSA is by cascading switches which do not all have
compatible taggers. Consider the following real-life topology:+---------------------------------------------------------------+
| LS1028A |
| +------------------------------+ |
| | DSA master for Felix | |
| |(internal ENETC port 2: eno2))| |
| +------------+------------------------------+-------------+ |
| | Felix embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
| | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
+--+-+--------------+---+--------------+---+--------------+--+--++-----------------------+ +-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+The above can be described in the device tree as follows (obviously not
complete):mscc_felix {
dsa,member = ;
ports {
port@4 {
ethernet = ;
};
};
};sja1105_switch1 {
dsa,member = ;
ports {
port@4 {
ethernet = ;
};
};
};sja1105_switch2 {
dsa,member = ;
ports {
port@4 {
ethernet = ;
};
};
};sja1105_switch3 {
dsa,member = ;
ports {
port@4 {
ethernet = ;
};
};
};Basically we instantiate one DSA switch tree for every hardware switch
in the system, but we still give them globally unique switch IDs (will
come back to that later). Having 3 disjoint switch trees makes the
tagger drivers "just work", because net devices are registered for the
3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
port. So packets received on the ENETC port are stripped of their
stacked DSA tags one by one.Currently, hardware bridging between ports on the same sja1105 chip is
possible, but switching between sja1105 ports on different chips is
handled by the software bridge. This is fine, but we can do better.In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
In other words, a sja1105 switch can correctly parse and route a packet
containing a dsa_8021q tag. So if we could enable hardware bridging on
the Felix DSA master ports, cross-chip bridging could be completely
offloaded.Such as system would be used as follows:
ip link add dev br0 type bridge && ip link set dev br0 up
for port in sw0p0 sw0p1 sw0p2 sw0p3 \
sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
doneThe above makes switching between ports on the same row be performed in
hardware, and between ports on different rows in software. Now assume
the Felix switch ports are called swp0, swp1, swp2. By running the
following extra commands:ip link add dev br1 type bridge && ip link set dev br1 up
for port in swp0 swp1 swp2; do
ip link set dev $port master br1
donethe CPU no longer sees packets which traverse sja1105 switch boundaries
and can be forwarded directly by Felix. The br1 bridge would not be used
for any sort of traffic termination.For this to work, we need to give drivers an opportunity to listen for
bridging events on DSA trees other than their own, and pass that other
tree index as argument. I have made the assumption, for the moment, that
the other existing DSA notifiers don't need to be broadcast to other
trees. That assumption might turn out to be incorrect. But in the
meantime, introduce a dsa_broadcast function, similar in purpose to
dsa_port_notify, which is used only by the bridging notifiers.Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Signed-off-by: Jakub Kicinski
28 Mar, 2020
1 commit
-
It is useful be able to configure port policers on a switch to accept
frames of various sizes:- Increase the MTU for better throughput from the default of 1500 if it
is known that there is no 10/100 Mbps device in the network.
- Decrease the MTU to limit the latency of high-priority frames under
congestion, or work around various network segments that add extra
headers to packets which can't be fragmented.For DSA slave ports, this is mostly a pass-through callback, called
through the regular ndo ops and at probe time (to ensure consistency
across all supported switches).The CPU port is called with an MTU equal to the largest configured MTU
of the slave ports. The assumption is that the user might want to
sustain a bidirectional conversation with a partner over any switch
port.The DSA master is configured the same as the CPU port, plus the tagger
overhead. Since the MTU is by definition L2 payload (sans Ethernet
header), it is up to each individual driver to figure out if it needs to
do anything special for its frame tags on the CPU port (it shouldn't
except in special cases). So the MTU does not contain the tagger
overhead on the CPU port.
However the MTU of the DSA master, minus the tagger overhead, is used as
a proxy for the MTU of the CPU port, which does not have a net device.
This is to avoid uselessly calling the .change_mtu function on the CPU
port when nothing should change.So it is safe to assume that the DSA master and the CPU port MTUs are
apart by exactly the tagger's overhead in bytes.Some changes were made around dsa_master_set_mtu(), function which was
now removed, for 2 reasons:
- dev_set_mtu() already calls dev_validate_mtu(), so it's redundant to
do the same thing in DSA
- __dev_set_mtu() returns 0 if ops->ndo_change_mtu is an absent method
That is to say, there's no need for this function in DSA, we can safely
call dev_set_mtu() directly, take the rtnl lock when necessary, and just
propagate whatever errors get reported (since the user probably wants to
be informed).Some inspiration (mainly in the MTU DSA notifier) was taken from a
vaguely similar patch from Murali and Florian, who are credited as
co-developers down below.Co-developed-by: Murali Krishna Policharla
Signed-off-by: Murali Krishna Policharla
Co-developed-by: Florian Fainelli
Signed-off-by: Florian Fainelli
Signed-off-by: Vladimir Oltean
Signed-off-by: David S. Miller
23 Oct, 2019
1 commit
-
Do not let the drivers access the ds->ports static array directly
while there is a dsa_to_port helper for this purpose.At the same time, un-const this helper since the SJA1105 driver
assigns the priv member of the returned dsa_port structure.Signed-off-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: Jakub Kicinski
28 Aug, 2019
2 commits
-
DSA currently programs a VLAN on the CPU port implicitly after the
related notifier is received by a switch.While we still need to do this transparent programmation of the DSA
links in the fabric, programming the CPU port this way may cause
problems in some corners such as the tag_8021q driver.Because the dedicated CPU port is specific to a slave, make their
programmation explicit a few layers up, in the slave code.Note that technically, DSA links have a dedicated CPU port as well,
but since they are only used as conduit between interconnected switches
of a fabric, programming them transparently this way is what we want.Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
The bitmap operations were introduced to simplify the switch drivers
in the future, since most of them could implement the common VLAN and
MDB operations (add, del, dump) with simple functions taking all target
ports at once, and thus limiting the number of hardware accesses.Programming an MDB or VLAN this way in a single operation would clearly
simplify the drivers a lot but would require a new get-set interface
in DSA. The usage of such bitmap from the stack also raised concerned
in the past, leading to the dynamic allocation of a new ds->_bitmap
member in the dsa_switch structure. So let's get rid of them for now.This commit nicely wraps the ds->ops->port_{mdb,vlan}_{prepare,add}
switch operations into new dsa_switch_{mdb,vlan}_{prepare,add}
variants not using any bitmap argument anymore.New dsa_switch_{mdb,vlan}_match helpers have been introduced to make
clear which local port of a switch must be programmed with the target
object. While the targeted user port is an obvious candidate, the
DSA links must also be programmed, as well as the CPU port for VLANs.While at it, also remove local variables that are only used once.
Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller
12 Aug, 2019
1 commit
-
The dsa framework has optional .port_mdb_{prepare,add,del} callback fields
for drivers to handle multicast database entries. When adding an entry, the
framework goes through a prepare phase, then a commit phase. Drivers not
providing these callbacks should be detected in the prepare phase.DSA core may still bypass the bridge layer and call the dsa_port_mdb_add
function directly with no prepare phase or no switchdev trans object,
and the framework ends up calling an undefined .port_mdb_add callback.
This results in a NULL pointer dereference, as shown in the log below.The other functions seem to be properly guarded. Do the same for
.port_mdb_add in dsa_switch_mdb_add_bitmap() as well.8] lr : [] psr: 80070013
sp : ee871db8 ip : 00000000 fp : ee98d0a4
r10: 0000000c r9 : 00000008 r8 : ee89f710
r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
r3 : 00000000 r2 : ee89f710 r1 : 00000008 r0 : ee98d040
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 6deb406a DAC: 00000051
Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
Stack: (0xee871db8 to 0xee872000)
1da0: ee871e14 103ace2d
1dc0: 00000000 ffffffff 00000000 ee871e14 00000005 00000000 c08524a0 00000000
1de0: ffffe000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000 c0851120 c014bef0
1e00: 00000000 b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710 ee871ecb 00000000
1e20: 00000008 103ace2d 00000000 c087e248 ee29c868 103ace2d 00000001 ffffffff
1e40: 00000000 ee871e98 00000006 00000000 c0fb2a50 c087e2d0 ffffffff c08523c4
1e60: ffffffff c014bdfc 00000006 c0fad2d0 ee871e98 ee89f710 00000000 c014c500
1e80: 00000000 ee89f3c0 c0f04c48 00000000 ee9e5000 c087dfb4 ee9e5000 00000000
1ea0: ee89f710 ee871ecb 00000001 103ace2d 00000000 c0f04c48 00000000 c087e0a8
1ec0: 00000000 efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710 ee9e5000 00000122
1ee0: 00000100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c 2e928000 c0fad2ec
1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 00000000 c087def8 c0fad2ec c01447dc
1f20: ef315640 ef7a62c0 00000008 ee839580 ee839594 ef7a62c0 00000008 c0f03d00
1f40: ef7a62d8 ef7a62c0 ffffe000 c0145b84 ffffe000 c0fb2420 c0bfaa8c 00000000
1f60: ffffe000 ee84b600 ee84b5c0 00000000 ee870000 ee839580 c0145b40 ef0e5ea4
1f80: ee84b61c c014a6f8 00000001 ee84b5c0 c014a5b0 00000000 00000000 00000000
1fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[] (dsa_switch_event) from [] (notifier_call_chain+0x48/0x84)
[] (notifier_call_chain) from [] (raw_notifier_call_chain+0x18/0x20)
[] (raw_notifier_call_chain) from [] (dsa_port_mdb_add+0x48/0x74)
[] (dsa_port_mdb_add) from [] (__switchdev_handle_port_obj_add+0x54/0xd4)
[] (__switchdev_handle_port_obj_add) from [] (switchdev_handle_port_obj_add+0x8/0x14)
[] (switchdev_handle_port_obj_add) from [] (dsa_slave_switchdev_blocking_event+0x94/0xa4)
[] (dsa_slave_switchdev_blocking_event) from [] (notifier_call_chain+0x48/0x84)
[] (notifier_call_chain) from [] (blocking_notifier_call_chain+0x50/0x68)
[] (blocking_notifier_call_chain) from [] (switchdev_port_obj_notify+0x44/0xa8)
[] (switchdev_port_obj_notify) from [] (switchdev_port_obj_add_now+0x90/0x104)
[] (switchdev_port_obj_add_now) from [] (switchdev_port_obj_add_deferred+0x14/0x5c)
[] (switchdev_port_obj_add_deferred) from [] (switchdev_deferred_process+0x64/0x104)
[] (switchdev_deferred_process) from [] (switchdev_deferred_process_work+0xc/0x14)
[] (switchdev_deferred_process_work) from [] (process_one_work+0x218/0x50c)
[] (process_one_work) from [] (worker_thread+0x44/0x5bc)
[] (worker_thread) from [] (kthread+0x148/0x150)
[] (kthread) from [] (ret_from_fork+0x14/0x2c)
Exception stack(0xee871fb0 to 0xee871ff8)
1fa0: 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: bad PC value
---[ end trace 1292c61abd17b130 ]---[] (dsa_switch_event) from [] (notifier_call_chain+0x48/0x84)
corresponds to$ arm-linux-gnueabihf-addr2line -C -i -e vmlinux c08533ec
linux/net/dsa/switch.c:156
linux/net/dsa/switch.c:178
linux/net/dsa/switch.c:328Fixes: e6db98db8a95 ("net: dsa: add switch mdb bitmap functions")
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Vivien Didelot
Signed-off-by: David S. Miller
31 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later versionextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman
01 May, 2019
2 commits
-
When ports are standalone (after they left the bridge), they should have
no VLAN filtering semantics (they should pass all traffic to the CPU).
Currently this is not true for switchdev drivers, because the bridge
"forgets" to unset that.Normally one would think that doing this at the bridge layer would be a
better idea, i.e. call br_vlan_filter_toggle() from br_del_if(), similar
to how nbp_vlan_init() is called from br_add_if().However what complicates that approach, and makes this one preferable,
is the fact that for the bridge core, vlan_filtering is a per-bridge
setting, whereas for switchdev/DSA it is per-port. Also there are
switches where the setting is per the entire device, and unsetting
vlan_filtering one by one, for each leaving port, would not be possible
from the bridge core without a certain level of awareness. So do this in
DSA and let drivers be unaware of it.Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
23 Feb, 2019
1 commit
-
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
19 Jul, 2018
1 commit
-
We avoid 2 VLAs by using a pre-allocated field in dsa_switch. We also
try to avoid dynamic allocation whenever possible (when using fewer than
bits-per-long ports, which is the common case).Link: http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com
Link: http://lkml.kernel.org/r/20180505185145.GB32630@lunn.ch
Signed-off-by: Salvatore Mesoraca
[kees: tweak commit subject and message slightly]
Signed-off-by: Kees Cook
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
03 Dec, 2017
5 commits
-
When a MAC address is added to or removed from a switch port in the
fabric, the target switch must program its port and adjacent switches
must program their local DSA port used to reach the target switch.For this purpose, use the dsa_towards_port() helper to identify the
local switch port which must be programmed.Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
This patch brings no functional changes.
It moves out the MDB code iterating on a multicast group into new
dsa_switch_mdb_{prepare,add}_bitmap() functions.This gives us a better isolation of the two switchdev phases.
Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
This patch brings no functional changes.
It moves out the VLAN code iterating on a list of VLAN members into new
dsa_switch_vlan_{prepare,add}_bitmap() functions.This gives us a better isolation of the two switchdev phases.
Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
The DSA switch MDB ops pass the switchdev_trans structure down to the
drivers, but no one is using them and they aren't supposed to anyway.Remove the trans argument from MDB prepare and add operations.
Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
The DSA switch VLAN ops pass the switchdev_trans structure down to the
drivers, but no one is using them and they aren't supposed to anyway.Remove the trans argument from VLAN prepare and add operations.
At the same time, fix the following checkpatch warning:
WARNING: line over 80 characters
#74: FILE: drivers/net/dsa/dsa_loop.c:177:
+ const struct switchdev_obj_port_vlan *vlan)Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller
12 Nov, 2017
1 commit
11 Nov, 2017
2 commits
-
The current code does not return after successfully preparing the VLAN
addition on every ports member of a it. Fix this.Fixes: 1ca4aa9cd4cc ("net: dsa: check VLAN capability of every switch")
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
The current code does not return after successfully preparing the MDB
addition on every ports member of a multicast group. Fix this.Fixes: a1a6b7ea7f2d ("net: dsa: add cross-chip multicast support")
Reported-by: Egil Hjelmeland
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
10 Nov, 2017
1 commit
-
Now that the host indicates when a multicast group should be forwarded
from the switch to the host, don't do it by default.Signed-off-by: Andrew Lunn
Signed-off-by: David S. Miller
08 Aug, 2017
3 commits
-
Currently, the switchdev objects are embedded inside the DSA notifier
info. This patch removes this dependency. This is done as a preparation
stage before adding support for learning FDB through the switchdev
notification chain.Signed-off-by: Arkadi Sharshevsky
Reviewed-by: Florian Fainelli
Reviewed-by: Vivien Didelot
Signed-off-by: David S. Miller -
The prepare phase for FDB add is unneeded because most of DSA devices
can have failures during bus transactions (SPI, I2C, etc.), thus, the
prepare phase cannot guarantee success of the commit stage.The support for learning FDB through notification chain, which will be
introduced in the following patches, will provide the ability to notify
back the bridge about successful offload.Signed-off-by: Arkadi Sharshevsky
Reviewed-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
In order to support FDB add/del to be on a notifier chain the slave
API need to be changed to be switchdev independent.Signed-off-by: Arkadi Sharshevsky
Reviewed-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
17 Jun, 2017
1 commit
-
Similarly to how cross-chip VLAN works, define a bitmap of multicast
group members for a switch, now including its DSA ports, so that
multicast traffic can be sent to all switches of the fabric.A switch may drop the frames if no user port is a member.
This brings support for multicast in a multi-chip environment.
As of now, all switches of the fabric must support the multicast
operations in order to program a single fabric port.Reported-by: Jason Cobham
Signed-off-by: Vivien Didelot
Tested-by: Jason Cobham
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
08 Jun, 2017
2 commits
-
In a multi-chip switch fabric, it is currently the responsibility of the
driver to add the CPU or DSA (interconnecting chips together) ports as
members of a new VLAN entry. This makes the drivers more complicated.We want the DSA drivers to be stupid and the DSA core being the one
responsible for caring about the abstracted switch logic and topology.Make the DSA core program the CPU and DSA ports as part of the VLAN.
This makes all chips of the data path to be aware of VIDs spanning the
the whole fabric and thus, seamlessly add support for cross-chip VLAN.Reviewed-by: Florian Fainelli
Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
Now that the VLAN object is propagated to every switch chip of the
switch fabric, we can easily ensure that they all support the required
VLAN operations before modifying an entry on a single switch.To achieve that, remove the condition skipping other target switches,
and add a bitmap of VLAN members, eventually containing the target port,
if we are programming the switch target.This will allow us to easily add other VLAN members, such as the DSA or
CPU ports (to introduce cross-chip VLAN support) or the other port
members if we want to reduce hardware accesses later.Reviewed-by: Florian Fainelli
Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller
25 May, 2017
1 commit
-
Now that the switchdev bridge ageing time attribute is propagated to all
switch chips of the fabric, each switch can check if the requested value
is valid and program itself, so that the whole fabric shares a common
ageing time setting.This is especially needed for switch chips in between others, containing
no bridge port members but evidently used in the data path.To achieve that, remove the condition which skips the other switches. We
also don't need to identify the target switch anymore, thus remove the
sw_index member of the dsa_notifier_ageing_time_info notifier structure.On ZII Dev Rev B (with two 88E6352 and one 88E6185) and ZII Dev Rev C
(with two 88E6390X), we have the following hardware configuration:# ip link add name br0 type bridge
# ip link set master br0 dev lan6
br0: port 1(lan6) entered blocking state
br0: port 1(lan6) entered disabled state
# echo 2000 > /sys/class/net/br0/bridge/ageing_timeBefore this patch:
zii-rev-b# cat /sys/kernel/debug/mv88e6xxx/sw*/age_time
300000
300000
15000zii-rev-c# cat /sys/kernel/debug/mv88e6xxx/sw*/age_time
300000
18750After this patch:
zii-rev-b# cat /sys/kernel/debug/mv88e6xxx/sw*/age_time
15000
15000
15000zii-rev-c# cat /sys/kernel/debug/mv88e6xxx/sw*/age_time
18750
18750Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
23 May, 2017
4 commits
-
Add two new DSA_NOTIFIER_VLAN_ADD and DSA_NOTIFIER_VLAN_DEL events to
notify not only a single switch, but all switches of a the fabric when
an VLAN entry is added or removed.For the moment, keep the current behavior and ignore other switches.
Signed-off-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Add two new DSA_NOTIFIER_MDB_ADD and DSA_NOTIFIER_MDB_DEL events to
notify not only a single switch, but all switches of a the fabric when
an MDB entry is added or removed.For the moment, keep the current behavior and ignore other switches.
Signed-off-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Add two new DSA_NOTIFIER_FDB_ADD and DSA_NOTIFIER_FDB_DEL events to
notify not only a single switch, but all switches of a the fabric when
an FDB entry is added or removed.For the moment, keep the current behavior and ignore other switches.
Signed-off-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
This patch keeps the port-wide ageing time handling code in
dsa_port_ageing_time, pushes the requested ageing time value in a new
switch fabric notification, and moves the switch-wide ageing time
handling code in dsa_switch_ageing_time.This has the effect that now not only the switch that the target port
belongs to can be programmed, but all switches composing the switch
fabric. For the moment, keep the current behavior and ignore other
switches.Signed-off-by: Vivien Didelot
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
18 May, 2017
1 commit
-
The public include/net/dsa.h file is meant for DSA drivers, while all
DSA core files share a common private header net/dsa/dsa_priv.h file.Ensure that dsa_priv.h is the only DSA core file to include net/dsa.h,
and add a new line to separate absolute and relative headers at the same
time.Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller
02 Apr, 2017
1 commit
-
Introduce crosschip_bridge_{join,leave} operations in the dsa_switch_ops
structure, which can be used by switches supporting interconnection.Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller
29 Mar, 2017
1 commit
-
I do not hold the copyright of the DSA core and drivers source files,
since these changes have been written as an initiative of my day job.
Fix this.Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
Acked-by: Florian Fainelli
Signed-off-by: David S. Miller
07 Feb, 2017
2 commits
-
A slave device will now notify the switch fabric once its port is
bridged or unbridged, instead of calling directly its switch operations.This code allows propagating cross-chip bridging events in the fabric.
Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller -
Add a notifier block per DSA switch, registered against a notifier head
in the switch fabric they belong to.This infrastructure will allow to propagate fabric-wide events such as
port bridging, VLAN configuration, etc. If a DSA switch driver cares
about cross-chip configuration, such events can be caught.Signed-off-by: Vivien Didelot
Signed-off-by: David S. Miller