kernel/linux.git/drivers/net/dsa, branch v5.10.78

net: dsa: mt7530: correct ds->num_ports

2021-10-27T07:56:52+00:00

commit 342afce10d6f61c443c95e244f812d4766f73f53 upstream. Setting ds->num_ports to DSA_MAX_PORTS made DSA core allocate unnecessary dsa_port's and call mt7530_port_disable for non-existent ports. Set it to MT7530_NUM_PORTS to fix that, and dsa_is_user_port check in port_enable/disable is no longer required. Cc: stable@vger.kernel.org Signed-off-by: DENG Qingfang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: dsa: lantiq_gswip: fix register definition

2021-10-27T07:56:48+00:00

[ Upstream commit 66d262804a2276721eac86cf18fcd61046149193 ] I compared the register definitions with the D-Link DWR-966 GPL sources and found that the PUAFD field definition was incorrect. This definition is unused and causes no issues. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Aleksander Jan Bajkowski Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: dsa: mv88e6xxx: don't use PHY_DETECT on internal PHY's

2021-10-20T09:45:06+00:00

commit 4a3e0aeddf091f00974b02627c157843ce382a24 upstream. mv88e6xxx_port_ppu_updates() interpretes data in the PORT_STS register incorrectly for internal ports (ie no PPU). In these cases, the PHY_DETECT bit indicates link status. This results in forcing the MAC state whenever the PHY link goes down which is not intended. As a side effect, LED's configured to show link status stay lit even though the physical link is down. Add a check in mac_link_down and mac_link_up to see if it concerns an external port and only then, look at PPU status. Fixes: 5d5b231da7ac (net: dsa: mv88e6xxx: use PHY_DETECT in mac_link_up/mac_link_down) Reported-by: Maarten Zanders Reviewed-by: Maxime Chevallier Signed-off-by: Maarten Zanders Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: dsa: microchip: Added the condition for scheduling ksz_mib_read_work

2021-10-20T09:45:04+00:00

commit ef1100ef20f29aec4e62abeccdb5bdbebba1e378 upstream. When the ksz module is installed and removed using rmmod, kernel crashes with null pointer dereferrence error. During rmmod, ksz_switch_remove function tries to cancel the mib_read_workqueue using cancel_delayed_work_sync routine and unregister switch from dsa. During dsa_unregister_switch it calls ksz_mac_link_down, which in turn reschedules the workqueue since mib_interval is non-zero. Due to which queue executed after mib_interval and it tries to access dp->slave. But the slave is unregistered in the ksz_switch_remove function. Hence kernel crashes. To avoid this crash, before canceling the workqueue, resetted the mib_interval to 0. v1 -> v2: -Removed the if condition in ksz_mib_read_work Fixes: 469b390e1ba3 ("net: dsa: microchip: use delayed_work instead of timer + work") Signed-off-by: Arun Ramadoss Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

dsa: mv88e6xxx: Include tagger overhead when setting MTU for DSA and CPU ports

2021-10-06T13:55:54+00:00

[ Upstream commit b9c587fed61cf88bd45822c3159644445f6d5aa6 ] Same members of the Marvell Ethernet switches impose MTU restrictions on ports used for connecting to the CPU or another switch for DSA. If the MTU is set too low, tagged frames will be discarded. Ensure the worst case tagger overhead is included in setting the MTU for DSA and CPU ports. Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU") Reported by: 曹煜 Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

dsa: mv88e6xxx: Fix MTU definition

2021-10-06T13:55:54+00:00

[ Upstream commit b92ce2f54c0f0ff781e914ec189c25f7bf1b1ec2 ] The MTU passed to the DSA driver is the payload size, typically 1500. However, the switch uses the frame size when applying restrictions. Adjust the MTU with the size of the Ethernet header and the frame checksum. The VLAN header also needs to be included when the frame size it per port, but not when it is global. Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU") Reported by: 曹煜 Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

dsa: mv88e6xxx: 6161: Use chip wide MAX MTU

2021-10-06T13:55:54+00:00

[ Upstream commit fe23036192c95b66e60d019d2ec1814d0d561ffd ] The datasheets suggests the 6161 uses a per port setting for jumbo frames. Testing has however shown this is not correct, it uses the old style chip wide MTU control. Change the ops in the 6161 structure to reflect this. Fixes: 1baf0fac10fb ("net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU") Reported by: 曹煜 Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: dsa: realtek: register the MDIO bus under devres

2021-09-30T08:11:02+00:00

[ Upstream commit 74b6d7d13307b016f4b5bba8198297824c0ee6df ] The Linux device model permits both the ->shutdown and ->remove driver methods to get called during a shutdown procedure. Example: a DSA switch which sits on an SPI bus, and the SPI bus driver calls this on its ->shutdown method: spi_unregister_controller -> device_for_each_child(&ctlr->dev, NULL, __unregister); -> spi_unregister_device(to_spi_device(dev)); -> device_del(&spi->dev); So this is a simple pattern which can theoretically appear on any bus, although the only other buses on which I've been able to find it are I2C: i2c_del_adapter -> device_for_each_child(&adap->dev, NULL, __unregister_client); -> i2c_unregister_device(client); -> device_unregister(&client->dev); The implication of this pattern is that devices on these buses can be unregistered after having been shut down. The drivers for these devices might choose to return early either from ->remove or ->shutdown if the other callback has already run once, and they might choose that the ->shutdown method should only perform a subset of the teardown done by ->remove (to avoid unnecessary delays when rebooting). So in other words, the device driver may choose on ->remove to not do anything (therefore to not unregister an MDIO bus it has registered on ->probe), because this ->remove is actually triggered by the device_shutdown path, and its ->shutdown method has already run and done the minimally required cleanup. This used to be fine until the blamed commit, but now, the following BUG_ON triggers: void mdiobus_free(struct mii_bus *bus) { /* For compatibility with error handling in drivers. */ if (bus->state == MDIOBUS_ALLOCATED) { kfree(bus); return; } BUG_ON(bus->state != MDIOBUS_UNREGISTERED); bus->state = MDIOBUS_RELEASED; put_device(&bus->dev); } In other words, there is an attempt to free an MDIO bus which was not unregistered. The attempt to free it comes from the devres release callbacks of the SPI device, which are executed after the device is unregistered. I'm not saying that the fact that MDIO buses allocated using devres would automatically get unregistered wasn't strange. I'm just saying that the commit didn't care about auditing existing call paths in the kernel, and now, the following code sequences are potentially buggy: (a) devm_mdiobus_alloc followed by plain mdiobus_register, for a device located on a bus that unregisters its children on shutdown. After the blamed patch, either both the alloc and the register should use devres, or none should. (b) devm_mdiobus_alloc followed by plain mdiobus_register, and then no mdiobus_unregister at all in the remove path. After the blamed patch, nobody unregisters the MDIO bus anymore, so this is even more buggy than the previous case which needs a specific bus configuration to be seen, this one is an unconditional bug. In this case, the Realtek drivers fall under category (b). To solve it, we can register the MDIO bus under devres too, which restores the previous behavior. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Reported-by: Lino Sanfilippo Reported-by: Alvin Šipraga Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: dsa: bcm_sf2: Fix array overrun in bcm_sf2_num_active_ports()

2021-09-22T10:28:07+00:00

commit 02319bf15acf54004216e40ac9c171437f24be24 upstream. After d12e1c464988 ("net: dsa: b53: Set correct number of ports in the DSA struct") we stopped setting dsa_switch::num_ports to DSA_MAX_PORTS, which created an off by one error between the statically allocated bcm_sf2_priv::port_sts array (of size DSA_MAX_PORTS). When dsa_is_cpu_port() is used, we end-up accessing an out of bounds member and causing a NPD. Fix this by iterating with the appropriate port count using ds->num_ports. Fixes: d12e1c464988 ("net: dsa: b53: Set correct number of ports in the DSA struct") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: dsa: b53: Fix IMP port setup on BCM5301x

2021-09-22T10:28:05+00:00

[ Upstream commit 63f8428b4077de3664eb0b252393c839b0b293ec ] Broadcom's b53 switches have one IMP (Inband Management Port) that needs to be programmed using its own designed register. IMP port may be different than CPU port - especially on devices with multiple CPU ports. For that reason it's required to explicitly note IMP port index and check for it when choosing a register to use. This commit fixes BCM5301x support. Those switches use CPU port 5 while their IMP port is 8. Before this patch b53 was trying to program port 5 with B53_PORT_OVERRIDE_CTRL instead of B53_GMII_PORT_OVERRIDE_CTRL(5). It may be possible to also replace "cpu_port" usages with dsa_is_cpu_port() but that is out of the scope of thix BCM5301x fix. Fixes: 967dd82ffc52 ("net: dsa: b53: Add support for Broadcom RoboSwitch") Signed-off-by: Rafał Miłecki Signed-off-by: David S. Miller Signed-off-by: Sasha Levin