linux-stable.git/drivers/net/dsa, branch linux-5.6.y

net: dsa: qca8k: Fix "Unexpected gfp" kernel exception

2020-06-17T14:41:48+00:00

[ Upstream commit 67122a7910bf2135dc7f7ececfcf16a5bdb362c1 ]

Commit 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper")
replaced the dsa_switch_alloc helper by devm_kzalloc in all DSA
drivers. Unfortunately it introduced a typo in qca8k.c driver and
wrong argument is passed to the devm_kzalloc function.

This fix mitigates the following kernel exception:

  Unexpected gfp: 0x6 (__GFP_HIGHMEM|GFP_DMA32). Fixing up to gfp: 0x101 (GFP_DMA|__GFP_ZERO). Fix your code!
  CPU: 1 PID: 44 Comm: kworker/1:1 Not tainted 5.5.9-yocto-ua #1
  Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
  Workqueue: events deferred_probe_work_func
  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
  [] (show_stack) from [] (dump_stack+0x90/0xa4)
  [] (dump_stack) from [] (new_slab+0x20c/0x214)
  [] (new_slab) from [] (___slab_alloc.constprop.0+0x1b8/0x540)
  [] (___slab_alloc.constprop.0) from [] (__slab_alloc.constprop.0+0x1c/0x24)
  [] (__slab_alloc.constprop.0) from [] (__kmalloc_track_caller+0x1b0/0x298)
  [] (__kmalloc_track_caller) from [] (devm_kmalloc+0x24/0x70)
  [] (devm_kmalloc) from [] (qca8k_sw_probe+0x94/0x1ac)
  [] (qca8k_sw_probe) from [] (mdio_probe+0x30/0x54)
  [] (mdio_probe) from [] (really_probe+0x1e0/0x348)
  [] (really_probe) from [] (driver_probe_device+0x60/0x16c)
  [] (driver_probe_device) from [] (bus_for_each_drv+0x70/0x94)
  [] (bus_for_each_drv) from [] (__device_attach+0xb4/0x11c)
  [] (__device_attach) from [] (bus_probe_device+0x84/0x8c)
  [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90)
  [] (deferred_probe_work_func) from [] (process_one_work+0x1d4/0x41c)
  [] (process_one_work) from [] (worker_thread+0x248/0x528)
  [] (worker_thread) from [] (kthread+0x124/0x150)
  [] (kthread) from [] (ret_from_fork+0x14/0x3c)
  Exception stack(0xee1b5fb0 to 0xee1b5ff8)
  5fa0:                                     00000000 00000000 00000000 00000000
  5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
  qca8k 2188000.ethernet-1:0a: Using legacy PHYLIB callbacks. Please migrate to PHYLINK!
  qca8k 2188000.ethernet-1:0a eth2 (uninitialized): PHY [2188000.ethernet-1:01] driver [Generic PHY]
  qca8k 2188000.ethernet-1:0a eth1 (uninitialized): PHY [2188000.ethernet-1:02] driver [Generic PHY]

Fixes: 7e99e3470172 ("net: dsa: remove dsa_switch_alloc helper")
Signed-off-by: Michal Vokáč 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: dsa: felix: send VLANs on CPU port as egress-tagged

2020-06-10T18:22:49+00:00

[ Upstream commit 183be6f967fe37c3154bfac39e913c3bafe89d1b ]

As explained in other commits before (b9cd75e66895 and 87b0f983f66f),
ocelot switches have a single egress-untagged VLAN per port, and the
driver would deny adding a second one while an egress-untagged VLAN
already exists.

But on the CPU port (where the VLAN configuration is implicit, because
there is no net device for the bridge to control), the DSA core attempts
to add a VLAN using the same flags as were used for the front-panel
port. This would make adding any untagged VLAN fail due to the CPU port
rejecting the configuration:

bridge vlan add dev swp0 vid 100 pvid untagged
[ 1865.854253] mscc_felix 0000:00:00.5: Port already has a native VLAN: 1
[ 1865.860824] mscc_felix 0000:00:00.5: Failed to add VLAN 100 to port 5: -16

(note that port 5 is the CPU port and not the front-panel swp0).

So this hardware will send all VLANs as tagged towards the CPU.

Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family")
Signed-off-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: dsa: mt7530: set CPU port to fallback mode

2020-06-07T11:16:49+00:00

commit 38152ea37d8bdaffa22603e0a5b5b86cfa8714c9 upstream.

Currently, setting a bridge's self PVID to other value and deleting
the default VID 1 renders untagged ports of that VLAN unable to talk to
the CPU port:

	bridge vlan add dev br0 vid 2 pvid untagged self
	bridge vlan del dev br0 vid 1 self
	bridge vlan add dev sw0p0 vid 2 pvid untagged
	bridge vlan del dev sw0p0 vid 1
	# br0 cannot send untagged frames out of sw0p0 anymore

That is because the CPU port is set to security mode and its PVID is
still 1, and untagged frames are dropped due to VLAN member violation.

Set the CPU port to fallback mode so untagged frames can pass through.

Fixes: 83163f7dca56 ("net: dsa: mediatek: add VLAN support for MT7530")
Signed-off-by: DENG Qingfang 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: Fix return value about devm_platform_ioremap_resource()

2020-06-07T11:16:48+00:00

[ Upstream commit ef24d6c3d6965158dfe23ae961d87e9a343e18a2 ]

When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.

Signed-off-by: Tiezhu Yang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: dsa: mt7530: fix roaming from DSA user ports

2020-06-03T06:22:40+00:00

[ Upstream commit 5e5502e012b8129e11be616acb0f9c34bc8f8adb ]

When a client moves from a DSA user port to a software port in a bridge,
it cannot reach any other clients that connected to the DSA user ports.
That is because SA learning on the CPU port is disabled, so the switch
ignores the client's frames from the CPU port and still thinks it is at
the user port.

Fix it by enabling SA learning on the CPU port.

To prevent the switch from learning from flooding frames from the CPU
port, set skb->offload_fwd_mark to 1 for unicast and broadcast frames,
and let the switch flood them instead of trapping to the CPU port.
Multicast frames still need to be trapped to the CPU port for snooping,
so set the SA_DIS bit of the MTK tag to 1 when transmitting those frames
to disable SA learning.

Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
Signed-off-by: DENG Qingfang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

felix: Fix initialization of ioremap resources

2020-06-03T06:22:39+00:00

[ Upstream commit b4024c9e5c57902155d3b5e7de482e245f492bff ]

The caller of devm_ioremap_resource(), either accidentally
or by wrong assumption, is writing back derived resource data
to global static resource initialization tables that should
have been constant.  Meaning that after it computes the final
physical start address it saves the address for no reason
in the static tables.  This doesn't affect the first driver
probing after reboot, but it breaks consecutive driver reloads
(i.e. driver unbind & bind) because the initialization tables
no longer have the correct initial values.  So the next probe()
will map the device registers to wrong physical addresses,
causing ARM SError async exceptions.
This patch fixes all of the above.

Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family")
Signed-off-by: Claudiu Manoil 
Reviewed-by: Vladimir Oltean 
Tested-by: Vladimir Oltean 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: dsa: loop: Add module soft dependency

2020-05-20T06:22:04+00:00

[ Upstream commit 3047211ca11bf77b3ecbce045c0aa544d934b945 ]

There is a soft dependency against dsa_loop_bdinfo.ko which sets up the
MDIO device registration, since there are no symbols referenced by
dsa_loop.ko, there is no automatic loading of dsa_loop_bdinfo.ko which
is needed.

Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
Signed-off-by: Florian Fainelli 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: dsa: ocelot: the MAC table on Felix is twice as large

2020-05-20T06:22:00+00:00

[ Upstream commit 21ce7f3e16fbf89faaf149cfe0f730edfc553914 ]

When running 'bridge fdb dump' on Felix, sometimes learnt and static MAC
addresses would appear, sometimes they wouldn't.

Turns out, the MAC table has 4096 entries on VSC7514 (Ocelot) and 8192
entries on VSC9959 (Felix), so the existing code from the Ocelot common
library only dumped half of Felix's MAC table. They are both organized
as a 4-way set-associative TCAM, so we just need a single variable
indicating the correct number of rows.

Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family")
Signed-off-by: Vladimir Oltean 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: dsa: b53: b53_arl_rw_op() needs to select IVL or SVL

2020-04-29T14:34:40+00:00

[ Upstream commit 64fec9493f7dc9bdd7233bcfe98985c45bd0e3c1 ]

Flip the IVL_SVL_SELECT bit correctly based on the VLAN enable status,
the default is to perform Shared VLAN learning instead of Individual
learning.

Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: dsa: b53: Rework ARL bin logic

2020-04-29T14:34:40+00:00

[ Upstream commit 6344dbde6a27d10d16246d734b968f84887841e2 ]

When asking the ARL to read a MAC address, we will get a number of bins
returned in a single read. Out of those bins, there can essentially be 3
states:

- all bins are full, we have no space left, and we can either replace an
  existing address or return that full condition

- the MAC address was found, then we need to return its bin index and
  modify that one, and only that one

- the MAC address was not found and we have a least one bin free, we use
  that bin index location then

The code would unfortunately fail on all counts.

Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations")
Signed-off-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman