kernel/git/stable/linux.git/drivers/net/ethernet/microchip, branch master

net: sparx5: fix sleep in atomic context in MAC table access

2026-08-22T20:21:26+00:00

sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() / sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget(). These take sparx5->lock, a mutex, and then poll the MAC access command register with readx_poll_timeout(). A mutex may block, which is not allowed from atomic context. Convert the driver to the new .ndo_set_rx_mode_async callback introduced in commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain. Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip preempt_count: 201, expected: 0 Call trace: __might_resched+0x144/0x248 __might_sleep+0x48/0x7c __mutex_lock+0x74/0x850 mutex_lock_nested+0x24/0x30 sparx5_mact_learn+0x78/0x100 sparx5_mc_sync+0x40/0x54 __hw_addr_sync_dev+0xc4/0x170 sparx5_set_rx_mode+0x4c/0x58 __dev_set_rx_mode+0x64/0xa4 __dev_open+0x1ec/0x26c Fixes: d6fce5141929 ("net: sparx5: add switching support") Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-2-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski

net: microchip: vcap: use port number instead of netdev name for debugfs

2026-08-22T20:21:26+00:00

sparx5_vcap_init() runs before sparx5_register_netdevs() in probe, and its debugfs setup calls vcap_port_debugfs() for every port using netdev_name(ndev) as the debugfs file name. At that point the netdevs have only been allocated, not registered, so dev->name still holds the "eth%d" template and netdev_name() returns "(unnamed net_device)". Every port tries to create the same file under vcaps/, producing a flood of warnings at boot: debugfs: '(unnamed net_device)' already exists in 'vcaps' debugfs: '(unnamed net_device)' already exists in 'vcaps' ... Add vcap_port_debugfs_portno(), a variant of vcap_port_debugfs() that takes the port's stable hardware port number and uses "p%u" as the debugfs file name instead of netdev_name(ndev). This makes the file name independent of registration order; the file still stores and later dereferences the netdev itself, same as before. sparx5 already reports the same "p%d" string via ndo_get_phys_port_name(), so the debugfs name now matches that. Only sparx5 (and lan969x, which shares this code) is switched to the new function. lan966x keeps calling vcap_port_debugfs() unchanged, so this fix does not rename any of its existing debugfs files. Fixes: b8909aad5b8d ("net: sparx5: move netdev and notifier block registration to probe") Signed-off-by: Daniel Machon Link: https://patch.msgid.link/20260817-misc-fixes-sparx5-lan969x-v3-1-c7c7fef723a8@microchip.com Signed-off-by: Jakub Kicinski

net: microchip: vcap api: Fix possible memory leak in vcap_decode_rule()

2026-08-05T01:03:29+00:00

The memory allocated for struct vcap_rule_internal, keyfields and actionfields inside vcap_dup_rule() are not freed in some of the error paths in vcap_decode_rule(). Fix that by calling vcap_free_rule(). Compile tested only. Issue found using a prototype static analysis tool built on top of the LLVM compiler infrastructure. Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Reviewed-by: Joe Damato Signed-off-by: Abdun Nihaal Link: https://patch.msgid.link/20260801055507.47534-1-nihaal@cse.iitm.ac.in Signed-off-by: Jakub Kicinski

net: lan743x: add support for RMII interface

2026-07-30T08:19:29+00:00

Enable RMII interface in the lan743x driver for PHY and MAC configuration. - Select RMII interface in lan743x_phy_interface_select(). - Update phylink supported_interfaces and MAC capabilities. - Enable RMII via RMII_CTL in lan743x_hardware_init(). - Define RMII_CTL register and enable bit in lan743x_main.h. EEE is not supported with RMII on PCI11x1x: the hardware does not implement LPI signaling over RMII. Clear RMII from lpi_interfaces to prevent phylink from enabling EEE on this interface. Signed-off-by: Thangaraj Samynathan Link: https://patch.msgid.link/20260723050827.694832-3-Thangaraj.S@microchip.com Signed-off-by: Paolo Abeni

net: lan743x: add RMII strap status detection for PCI11x1x

2026-07-30T08:19:29+00:00

Extend pci11x1x_strap_get_status() to read the RMII strap bits from the STRAP_READ register. The is_rmii_en flag is initialized to false and updated based on the hardware strap only if SGMII is not already enabled. This ensures correct interface identification during adapter initialization. Update the netif_dbg() to report the selected interface as SGMII, RMII, or RGMII. Signed-off-by: Thangaraj Samynathan Link: https://patch.msgid.link/20260723050827.694832-2-Thangaraj.S@microchip.com Signed-off-by: Paolo Abeni

net: ethernet: oa_tc6: add OA_TC6_BROKEN_PHY quirk flag

2026-07-21T08:53:24+00:00

Some MAC-PHY devices need custom MDIO bus access functions to work around hardware issues. Add the OA_TC6_BROKEN_PHY quirk flag so drivers can opt in to skip oa_tc6's internal PHY init and manage the PHY themselves. When the flag is set, oa_tc6 skips MDIO bus registration, PHY discovery and PHY connection, leaving these to the driver. Drivers that do not set the flag retain the existing behavior. Update lan865x and the framework documentation accordingly. Signed-off-by: Ciprian Regus Link: https://patch.msgid.link/20260708-adin1140-driver-v5-3-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni

net: sparx5: configure TAS port link speed

2026-07-21T08:03:09+00:00

On the TSN and RED variants of LAN969x and SparX-5i TAS (Time-Aware Shaper) is present in the silicon. Currently, the driver does not use configure it at all, which means that the TAS_PROFILE_CONFIG.LINK_SPEED[1] value is left at the default of 3 which means that its configured for 1 Gbps. So, running iperf between two 10G switch ports will result in only 940-ish Mbps while we should be getting around 9.3 Gbps. Correctly populating the TAS_PROFILE_CONFIG.LINK_SPEED[1] with the current port speed fixes this issue and we achieve around 9.4 Gbps between two 10G switch ports. So, port the TAS port link speed setting from the vendor BSP 6.18 kernel[2] [1] https://microchip-ung.github.io/lan969x-industrial_reginfo/reginfo_LAN969x-Industrial.html?select=hsch,tas_profile_cfg,tas_profile_config,link_speed [2] https://github.com/microchip-ung/linux/tree/bsp-6.18-2026 Signed-off-by: Robert Marko Link: https://patch.msgid.link/20260707170531.1129866-1-robert.marko@sartura.hr Signed-off-by: Paolo Abeni

net: microchip: vcap: fix races on the shared Super VCAP block

2026-07-05T07:18:47+00:00

The VCAP instances on a chip are not independent, yet they are locked independently. On sparx5 and lan969x the IS0 and IS2 instances are backed by the same Super VCAP hardware block and share its cache and command registers: every access drives the shared VCAP_SUPER_CTRL register and moves data through the shared cache registers. Accessing one instance therefore races with accessing another. The per-instance admin->lock cannot prevent this, as each instance takes a different lock. The locking issue is mostly disguised by the fact that the core usage of the vcap api runs under rtnl. However, the full rule dump in debugfs decodes rules straight from hardware (a READ command followed by a cache read) and runs outside rtnl, so it races a concurrent tc-flower rule write to another Super VCAP instance. Besides corrupting the dump, the read repopulates the shared cache between the writers cache fill and its write command, so the writer commits the wrong data and corrupts the hardware entry. Introduce vcap_lock() and vcap_unlock() helpers and route every rule lock site in the VCAP API and its debugfs code through them. Replace the per-instance admin->lock with a single mutex in struct vcap_control that serializes access to all instances. The helpers reach it through a new admin->vctrl back-pointer, and the clients initialise and destroy the control lock instead of a per-instance one. No path holds more than one instance lock, so collapsing them onto a single mutex cannot self-deadlock. Fixes: 71c9de995260 ("net: microchip: sparx5: Add VCAP locking to protect rules") Signed-off-by: Jens Emil Schulz Østergaard Link: https://patch.msgid.link/20260630-microchip_fix_vcap_locking-v1-1-f60a4596734d@microchip.com Signed-off-by: Paolo Abeni

net: lan743x: Initialize eth_syslock spinlock before use

2026-06-30T10:13:20+00:00

lan743x_hardware_init() calls pci11x1x_strap_get_status() during the PCI11x1x probe sequence. That helper acquires the Ethernet subsystem hardware lock via lan743x_hs_syslock_acquire(), which relies on adapter->eth_syslock_spinlock to serialize access. The spinlock is currently initialized only after the strap status is read. With CONFIG_DEBUG_SPINLOCK enabled, taking the zeroed initialized spinlock can trip the spinlock debug check. Fix by initializing adapter->eth_syslock_spinlock before reading the strap status so the probe path never attempts to lock an uninitialized spinlock. Fixes: 46b777ad9a8c ("net: lan743x: Add support to SGMII 1G and 2.5G") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Andrea Righi Reviewed-by: David Thompson Reviewed-by: Thangaraj Samynathan Link: https://patch.msgid.link/20260626163218.3591486-1-arighi@nvidia.com Signed-off-by: Paolo Abeni

net: sparx5: unregister blocking notifier on init failure

2026-06-25T15:54:04+00:00

sparx5_register_notifier_blocks() registers the switchdev blocking notifier before allocating the ordered workqueue. If the workqueue allocation fails, the error path unregisters the switchdev and netdevice notifiers, but leaves the blocking notifier registered. Add a separate error label for the workqueue allocation failure path and unregister the switchdev blocking notifier there. Fixes: d6fce5141929 ("net: sparx5: add switching support") Cc: stable@vger.kernel.org Signed-off-by: Haoxiang Li Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260623115714.2192074-1-haoxiang_li2024@163.com Signed-off-by: Jakub Kicinski