kernel/drivers/net/ethernet/microchip/lan966x/lan966x_switchdev.c, branch linux-6.18.y

net: lan966x: Make sure to insert the vlan tags also in host mode

2025-05-29T13:48:37Z

When running these commands on DUT (and similar at the other end) ip link set dev eth0 up ip link add link eth0 name eth0.10 type vlan id 10 ip addr add 10.0.0.1/24 dev eth0.10 ip link set dev eth0.10 up ping 10.0.0.2 The ping will fail. The reason why is failing is because, the network interfaces for lan966x have a flag saying that the HW can insert the vlan tags into the frames(NETIF_F_HW_VLAN_CTAG_TX). Meaning that the frames that are transmitted don't have the vlan tag inside the skb data, but they have it inside the skb. We already get that vlan tag and put it in the IFH but the problem is that we don't configure the HW to rewrite the frame when the interface is in host mode. The fix consists in actually configuring the HW to insert the vlan tag if it is different than 0. Reviewed-by: Maxime Chevallier Fixes: 6d2c186afa5d ("net: lan966x: Add vlan support.") Signed-off-by: Horatiu Vultur Link: https://patch.msgid.link/20250528093619.3738998-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni

net: lan966x: Extend FDB to support also lag

2022-08-22T13:00:54Z

Offload FDB entries when the original device is a lag interface. Because all the ports under the lag have the same chip id, which is the chip id of first port, then add the entries only for the first port. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller

net: lan966x: Add lag support for lan966x

2022-08-22T13:00:54Z

Add link aggregation hardware offload support for lan966x Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller

net: lan966x: Extend lan966x_foreign_bridging_check

2022-08-22T13:00:54Z

Extend lan966x_foreign_bridging_check to check also if the upper interface is a lag device. Don't allow a lan966x port to be part of a lag if it has foreign interfaces. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller

net: lan966x: Expose lan966x_switchdev_nb and lan966x_switchdev_blocking_nb

2022-08-22T13:00:54Z

Expose lan966x_switchdev_nb and lan966x_switchdev_blocking_nb to the lan966x_main.h file because they will be needed by the lag driver. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller

net: lan966x: Flush fdb workqueue when port is leaving a bridge.

2022-08-22T13:00:54Z

Whenever a port leaves a bridge, flush the workqueue of the FDB work. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller

net: lan966x: Fix when a port's upper is changed.

2022-04-12T03:47:15Z

On lan966x it is not allowed to have foreign interfaces under a bridge which already contains lan966x ports. So when a port leaves the bridge it would call switchdev_bridge_port_unoffload which eventually will notify the other ports that bridge left the vlan group but that is not true because the bridge is still part of the vlan group. Therefore when a port leaves the bridge, stop generating replays because already the HW cleared after itself and the other ports don't need to do anything else. Fixes: cf2f60897e921e ("net: lan966x: Add support to offload the forwarding.") Signed-off-by: Horatiu Vultur Signed-off-by: Jakub Kicinski

net: switchdev: remove lag_mod_cb from switchdev_handle_fdb_event_to_device

2022-02-25T05:31:43Z

When the switchdev_handle_fdb_event_to_device() event replication helper was created, my original thought was that FDB events on LAG interfaces should most likely be special-cased, not just replicated towards all switchdev ports beneath that LAG. So this replication helper currently does not recurse through switchdev lower interfaces of LAG bridge ports, but rather calls the lag_mod_cb() if that was provided. No switchdev driver uses this helper for FDB events on LAG interfaces yet, so that was an assumption which was yet to be tested. It is certainly usable for that purpose, as my RFC series shows: https://patchwork.kernel.org/project/netdevbpf/cover/20220210125201.2859463-1-vladimir.oltean@nxp.com/ however this approach is slightly convoluted because: - the switchdev driver gets a "dev" that isn't its own net device, but rather the LAG net device. It must call switchdev_lower_dev_find(dev) in order to get a handle of any of its own net devices (the ones that pass check_cb). - in order for FDB entries on LAG ports to be correctly refcounted per the number of switchdev ports beneath that LAG, we haven't escaped the need to iterate through the LAG's lower interfaces. Except that is now the responsibility of the switchdev driver, because the replication helper just stopped half-way. So, even though yes, FDB events on LAG bridge ports must be special-cased, in the end it's simpler to let switchdev_handle_fdb_* just iterate through the LAG port's switchdev lowers, and let the switchdev driver figure out that those physical ports are under a LAG. The switchdev_handle_fdb_event_to_device() helper takes a "foreign_dev_check" callback so it can figure out whether @dev can autonomously forward to @foreign_dev. DSA fills this method properly: if the LAG is offloaded by another port in the same tree as @dev, then it isn't foreign. If it is a software LAG, it is foreign - forwarding happens in software. Whether an interface is foreign or not decides whether the replication helper will go through the LAG's switchdev lowers or not. Since the lan966x doesn't properly fill this out, FDB events on software LAG uppers will get called. By changing lan966x_foreign_dev_check(), we can suppress them. Whereas DSA will now start receiving FDB events for its offloaded LAG uppers, so we need to return -EOPNOTSUPP, since we currently don't do the right thing for them. Cc: Horatiu Vultur Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski

net: lan966x: remove guards against !BRIDGE_VLAN_INFO_BRENTRY

2022-02-17T14:17:09Z

Since commit 3116ad0696dd ("net: bridge: vlan: don't notify to switchdev master VLANs without BRENTRY flag"), the bridge no longer emits switchdev notifiers for VLANs that don't have the BRIDGE_VLAN_INFO_BRENTRY flag, so these checks are dead code. Remove them. Signed-off-by: Vladimir Oltean Reviewed-by: Horatiu Vultur Signed-off-by: David S. Miller

net: lan966x: Update mdb when enabling/disabling mcast_snooping

2022-02-05T15:00:43Z

When the multicast snooping is disabled, the mdb entries should be removed from the HW, but they still need to be kept in memory for when the mcast_snooping will be enabled again. Signed-off-by: Horatiu Vultur Signed-off-by: David S. Miller