diff options
author | DENG Qingfang <dqfext@gmail.com> | 2021-02-22 13:38:11 +0800 |
---|---|---|
committer | Hauke Mehrtens <hauke@hauke-m.de> | 2021-02-23 21:10:56 +0100 |
commit | 920eaab1d8179035d0ae1047e75cf9a50da6a6eb (patch) | |
tree | 14c29956bb33e682f304c643247aa023dd7ec211 /target/linux/generic/pending-5.10/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch | |
parent | 90b1524f75023ad0f441e82773ca9e9b5d513e1a (diff) | |
download | upstream-920eaab1d8179035d0ae1047e75cf9a50da6a6eb.tar.gz upstream-920eaab1d8179035d0ae1047e75cf9a50da6a6eb.tar.bz2 upstream-920eaab1d8179035d0ae1047e75cf9a50da6a6eb.zip |
kernel: DSA roaming fix for Marvell mv88e6xxx
Marvell mv88e6xxx switch series cannot perform MAC learning from
CPU-injected (FROM_CPU) DSA frames, which results in 2 issues.
- excessive flooding, due to the fact that DSA treats those addresses
as unknown
- the risk of stale routes, which can lead to temporary packet loss
Backport those patch series from netdev mailing list, which solve these
issues by adding and clearing static entries to the switch's FDB.
Add a hack patch to set default VID to 1 in port_fdb_{add,del}. Otherwise
the static entries will be added to the switch's private FDB if VLAN
filtering disabled, which will not work.
The switch may generate an "ATU violation" warning when a client moves
from the CPU port to a switch port because the static ATU entry added by
DSA core still points to the CPU port. DSA core will then clear the static
entry so it is not fatal. Disable the warning so it will not confuse users.
Link: https://lore.kernel.org/netdev/20210106095136.224739-1-olteanv@gmail.com/
Link: https://lore.kernel.org/netdev/20210116012515.3152-1-tobias@waldekranz.com/
Ref: https://gitlab.nic.cz/turris/turris-build/-/issues/165
Signed-off-by: DENG Qingfang <dqfext@gmail.com>
Diffstat (limited to 'target/linux/generic/pending-5.10/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch')
-rw-r--r-- | target/linux/generic/pending-5.10/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch | 27 |
1 files changed, 27 insertions, 0 deletions
diff --git a/target/linux/generic/pending-5.10/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch b/target/linux/generic/pending-5.10/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch new file mode 100644 index 0000000000..5b8d058247 --- /dev/null +++ b/target/linux/generic/pending-5.10/768-net-dsa-mv88e6xxx-Request-assisted-learning-on-CPU-port.patch @@ -0,0 +1,27 @@ +From: Tobias Waldekranz <tobias@waldekranz.com> +Subject: [RFC net-next 7/7] net: dsa: mv88e6xxx: Request assisted learning on CPU port +Date: Sat, 16 Jan 2021 02:25:15 +0100 +Archived-At: <https://lore.kernel.org/netdev/20210116012515.3152-8-tobias@waldekranz.com/> + +While the hardware is capable of performing learning on the CPU port, +it requires alot of additions to the bridge's forwarding path in order +to handle multi-destination traffic correctly. + +Until that is in place, opt for the next best thing and let DSA sync +the relevant addresses down to the hardware FDB. + +Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> +--- + drivers/net/dsa/mv88e6xxx/chip.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/dsa/mv88e6xxx/chip.c ++++ b/drivers/net/dsa/mv88e6xxx/chip.c +@@ -5405,6 +5405,7 @@ static int mv88e6xxx_register_switch(str + ds->ops = &mv88e6xxx_switch_ops; + ds->ageing_time_min = chip->info->age_time_coeff; + ds->ageing_time_max = chip->info->age_time_coeff * U8_MAX; ++ ds->assisted_learning_on_cpu_port = true; + + dev_set_drvdata(dev, ds); + |