kernel.git/drivers/net/ethernet/microchip, branch linux-5.18.y

net: lan966x: Fix usage of lan966x->mac_lock when used by FDB

2022-07-29T15:28:07Z

[ Upstream commit 675c807ae26b267233b97cd5006979a6bb8d54d4 ] When the SW bridge was trying to add/remove entries to/from HW, the access to HW was not protected by any lock. In this way, it was possible to have race conditions. Fix this by using the lan966x->mac_lock to protect parallel access to HW for this cases. Fixes: 25ee9561ec622 ("net: lan966x: More MAC table functionality") Signed-off-by: Horatiu Vultur Reviewed-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: lan966x: Fix usage of lan966x->mac_lock inside lan966x_mac_irq_handler

2022-07-29T15:28:07Z

[ Upstream commit c1924684369762b112428a333ad00eac6ca89d96 ] The problem with this spin lock is that it was just protecting the list of the MAC entries in SW and not also the access to the MAC entries in HW. Because the access to HW is indirect, then it could happen to have race conditions. For example when SW introduced an entry in MAC table and the irq mac is trying to read something from the MAC. Update such that also the access to MAC entries in HW is protected by this lock. Fixes: 5ccd66e01cbef ("net: lan966x: add support for interrupts from analyzer") Signed-off-by: Horatiu Vultur Reviewed-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: lan966x: Fix usage of lan966x->mac_lock when entry is removed

2022-07-29T15:28:07Z

[ Upstream commit 99343cfa4f7560abf933fff7ab3ea58a6905c917 ] To remove an entry to the MAC table, it is required first to setup the entry and then issue a command for the MAC to forget the entry. So if it happens for two threads to remove simultaneously an entry in MAC table then it would be a race condition. Fix this by using lan966x->mac_lock to protect the HW access. Fixes: e18aba8941b40 ("net: lan966x: add mactable support") Signed-off-by: Horatiu Vultur Reviewed-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: lan966x: Fix usage of lan966x->mac_lock when entry is added

2022-07-29T15:28:07Z

[ Upstream commit 43243bb3195b0dc27741679471e23baed1efe98e ] To add an entry to the MAC table, it is required first to setup the entry and then issue a command for the MAC to learn the entry. So if it happens for two threads to add simultaneously an entry in MAC table then it would be a race condition. Fix this by using lan966x->mac_lock to protect the HW access. Fixes: fc0c3fe7486f2 ("net: lan966x: Add function lan966x_mac_ip_learn()") Signed-off-by: Horatiu Vultur Reviewed-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: lan966x: Fix taking rtnl_lock while holding spin_lock

2022-07-29T15:28:07Z

[ Upstream commit 45533a534a45cb12c20c81615d17306176cb1c57 ] When the HW deletes an entry in MAC table then it generates an interrupt. The SW will go through it's own list of MAC entries and if it is not found then it would notify the listeners about this. The problem is that when the SW will go through it's own list it would take a spin lock(lan966x->mac_lock) and when it notifies that the entry is deleted. But to notify the listeners it taking the rtnl_lock which is illegal. This is fixed by instead of notifying right away that the entry is deleted, move the entry on a temp list and once, it checks all the entries then just notify that the entries from temp list are deleted. Fixes: 5ccd66e01cbe ("net: lan966x: add support for interrupts from analyzer") Signed-off-by: Horatiu Vultur Reviewed-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: lan966x: hardcode the number of external ports

2022-07-12T14:42:14Z

commit e6fa930f73a15238f3cb0c204e2f786c919b815c upstream. Instead of counting the child nodes in the device tree, hardcode the number of ports in the driver itself. The counting won't work at all if an ethernet port is marked as disabled, e.g. because it is not connected on the board at all. It turns out that the LAN9662 and LAN9668 use the same switching IP with the same synthesis parameters. The only difference is that the output ports are not connected. Thus, we can just hardcode the number of physical ports to 8. Fixes: db8bcaad5393 ("net: lan966x: add the basic lan966x driver") Signed-off-by: Michael Walle Reviewed-by: Horatiu Vultur Link: https://lore.kernel.org/r/20220704153654.1167886-1-michael@walle.cc Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

net: sparx5: mdb add/del handle non-sparx5 devices

2022-07-07T15:55:00Z

[ Upstream commit 9c5de246c1dbe785268fc2e83c88624b92e4ec93 ] When adding/deleting mdb entries on other net_devices, eg., tap interfaces, it should not crash. Fixes: 3bacfccdcb2d ("net: sparx5: Add mdb handlers") Signed-off-by: Casper Andersson Reviewed-by: Steen Hegelund Link: https://lore.kernel.org/r/20220630122226.316812-1-casper.casan@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: sparx5: Add handling of host MDB entries

2022-07-07T15:55:00Z

[ Upstream commit 1c1ed5a48411e1686997157c21633653fbe045c6 ] Handle adding and removing MDB entries for host Signed-off-by: Casper Andersson Link: https://lore.kernel.org/r/20220503093922.1630804-1-casper.casan@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

net: lan966x: check devm_of_phy_get() for -EDEFER_PROBE

2022-06-14T16:44:54Z

[ Upstream commit b58cdd4388b1d8f5bee9f5a3897a7e780d1eaa48 ] At the moment, if devm_of_phy_get() returns an error the serdes simply isn't set. While it is bad to ignore an error in general, there is a particular bug that network isn't working if the serdes driver is compiled as a module. In that case, devm_of_phy_get() returns -EDEFER_PROBE and the error is silently ignored. The serdes is optional, it is not there if the port is using RGMII, in which case devm_of_phy_get() returns -ENODEV. Rearrange the error handling so that -ENODEV will be handled but other error codes will abort the probing. Fixes: d28d6d2e37d1 ("net: lan966x: add port module support") Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20220525231239.1307298-1-michael@walle.cc Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: lan966x: Fix assignment of the MAC address

2022-05-17T08:03:14Z

The following two scenarios were failing for lan966x. 1. If the port had the address X and then trying to assign the same address, then the HW was just removing this address because first it tries to learn new address and then delete the old one. As they are the same the HW remove it. 2. If the port eth0 was assigned the same address as one of the other ports eth1 then when assigning back the address to eth0 then the HW was deleting the address of eth1. The case 1. is fixed by checking if the port has already the same address while case 2. is fixed by checking if the address is used by any other port. Fixes: e18aba8941b40b ("net: lan966x: add mactable support") Signed-off-by: Horatiu Vultur Link: https://lore.kernel.org/r/20220513180030.3076793-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni