kernel/git/stable/linux.git/drivers/net/dsa, branch master

net: dsa: mxl862xx: enable assisted learning on CPU port

2026-08-27T18:41:25+00:00

The MxL862xx driver enables FDB isolation but does not enable assisted learning on the CPU port. Consequently, MAC addresses learned through a physical switch port are not updated in hardware when the corresponding station moves to a foreign bridge port, such as a Wi-Fi interface. The stale hardware FDB entry continues directing return traffic toward the original physical port. Traffic entering that same port is then filtered instead of being forwarded to the CPU and software bridge. This causes downstream unicast traffic, including DHCP OFFER and ACK packets, to disappear after a client roams to a local wireless interface. The client eventually considers the connection unusable and disconnects. Enable assisted CPU-port learning so DSA installs foreign bridge FDB entries on the CPU port. This keeps the hardware FDB synchronized with the software bridge and allows return traffic to reach locally attached Wi-Fi clients after roaming. Tested on a BPI R4 PRO with a MxL862xx switch and a BE14000 WiFi interface. - Without patch, wired uplink on lan6 port (mxl path) Wifi clients connect but roam away not getting DHCP offers - Without patch, wired uplink on wan port (no mxl path) Wifi clients connect and roam successfully - With this patch, uplink on lan6 (mxl path) Wifi clients connect and roam successfully Fixes: 340bdf984613 ("net: dsa: mxl862xx: implement bridge offloading") Signed-off-by: Edoardo Pinci Link: https://patch.msgid.link/DU0P251MB069949C6DEB4D1D51F31FE87C4A02@DU0P251MB0699.EURP251.PROD.OUTLOOK.COM Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-08-18T17:42:41+00:00

Merge in late fixes in preparation for the net-next PR. Conflicts: drivers/dpll/dpll_core.c drivers/dpll/dpll_netlink.c 33f016b23a219 ("dpll: fix NULL deref in dpll_device_ops() during teardown race") b1d0c412088e3 ("dpll: add STATE_CONNECTED_OVERRIDE pin capability") https://lore.kernel.org/aoR9YYY2P5--3x0N@sirena.org.uk https://lore.kernel.org/aoR9VmKllVGwmQn_@sirena.org.uk No adjacent changes. Signed-off-by: Jakub Kicinski

net: dsa: initial support for MT7628 embedded switch

2026-08-18T13:50:13+00:00

Add support for the MT7628 embedded switch. The switch has 5 built-in 100Mbps user ports (ports 0-4) and one 1Gbps port that is internally attached to the SoCs CPU MAC and serves as the CPU port. The switch hardware has a very limited 16 entry VLAN table. Configuring VLANs is the only way to control switch forwarding. Currently 6 entries are used by tag_8021q to isolate the ports. Double tag feature is enabled to force the switch to append the VLAN tag even if the incoming packet is already tagged, this simulates VLAN-unaware functionality and simplifies the tagger implementation. Signed-off-by: Joris Vaisvila Reviewed-by: Daniel Golle Link: https://patch.msgid.link/20260813190241.789323-5-joey@tinyisr.com Signed-off-by: Paolo Abeni

net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO

2026-08-18T01:26:18+00:00

rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical. When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns: WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61 Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT) Workqueue: events_unbound deferred_probe_work_func pc : gpiod_set_value+0x44/0x80 lr : rtl83xx_probe+0x1d8/0x3a0 Call trace: gpiod_set_value+0x44/0x80 (P) rtl83xx_probe+0x1d8/0x3a0 realtek_mdio_probe+0x24/0xa0 mdio_probe+0x38/0x78 really_probe+0xc4/0x3e0 __driver_probe_device+0x15c/0x1b8 driver_probe_device+0xb4/0x120 __device_attach_driver+0xb8/0x1a0 bus_for_each_drv+0x88/0xf0 __device_attach+0xa0/0x1d8 device_initial_probe+0x54/0x68 bus_probe_device+0x38/0xa0 deferred_probe_work_func+0xb8/0x120 process_one_work+0x184/0x4e8 worker_thread+0x188/0x308 kthread+0x130/0x150 ret_from_fork+0x10/0x20 Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning. The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19. The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xx_reset_assert() and rtl83xx_reset_deassert() helpers (both in v6.9). This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiod_set_value_cansleep() conversion at the corresponding open-coded call sites. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Cc: # 6.9.x Signed-off-by: Ahmad Fatoum Co-developed-by: Oleksij Rempel Signed-off-by: Oleksij Rempel Reviewed-by: Alvin Šipraga Reviewed-by: Linus Walleij Reviewed-by: Luiz Angelo Daros de Luca Link: https://patch.msgid.link/20260814110102.2362246-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski

net: dsa: mv88e6xxx: Fix PCS link check on CMODE read error

2026-08-17T23:44:42+00:00

mv88e6352_pcs_link_check() ignores errors returned by port_get_cmode(). If the port status register read fails, mv88e6352_port_get_cmode() returns without setting cmode. The link check then compares an uninitialized value and may incorrectly treat the PCS as active. Save the return value and fail the link check after releasing the register lock. marvell_c22_pcs_get_state() initializes the reported link state to down before calling the check, so a read failure is handled safely until a later poll succeeds. This issue was found by a static analysis checker and confirmed by manual source review. Fixes: 85764555442f ("net: dsa: mv88e6xxx: convert 88e6352 to phylink_pcs") Signed-off-by: Ruoyu Wang Reviewed-by: Vladimir Oltean Link: https://patch.msgid.link/20260813153131.3952970-1-ruoyuw560@gmail.com Signed-off-by: Jakub Kicinski

net: dsa: b53: fix error propagation from b53_fdb_dump()

2026-08-17T20:48:16+00:00

The blamed commit replaced "return ret" statements in b53_fdb_dump() with "break;" which jumps to the mutex_unlock() -> return 0 section. This is notably problematic because it swallows errors from the b53_fdb_copy() -> cb() path, and this will result in FDB dump truncation when the netlink skb overflows - see commit 21b52fed928e ("net: dsa: sja1105: fix broken backpressure in .port_fdb_dump"). Let's go back to "return ret". We don't need to preinitialize "ret" with 0, because the "do {} while" block guarantees we cannot reach the end of the function without at least once calling b53_arl_search_wait(), which will have initialized ret to some valid value. Fixes: f7eb4a1c0864 ("net: dsa: b53: serialize access to the ARL table") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Link: https://patch.msgid.link/20260812201121.2012356-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski

net: dsa: mt7530: serialize the regmap IRQ chip like every other user

2026-08-07T23:39:02+00:00

The switch register regmap is created with .disable_locking = true; every other user in this driver calls mt7530_mutex_lock()/unlock() around it, which takes priv->bus->mdio_lock, since the underlying mt7530_regmap_read()/write() issue raw, unserialized bus->read()/ write() MDIO transactions. mt7530_setup_irq() hands this same unlocked regmap straight to devm_regmap_add_irq_chip_fwnode(), whose threaded IRQ handler then calls regmap_read()/regmap_update_bits() on it without ever calling mt7530_mutex_lock(). An interrupt firing while another thread is mid-transaction on the same regmap (e.g. a paged register access, or an indirect PHY access) can interleave with the IRQ handler's own paged access and corrupt page selection on either side. Use struct regmap_irq_chip's handle_mask_sync hook to call mt7530_mutex_lock()/unlock() around the mask register write regmap-irq issues whenever a consumer of one of the mapped sub-IRQs enables, disables, requests or frees its line. This needs a per-device copy of mt7530_regmap_irq_chip, since devm_regmap_add_irq_chip_fwnode() keeps a pointer to it rather than copying it. handle_pre_irq/handle_post_irq, which would additionally cover the status read and ack write the threaded handler does directly, bracket the whole handler including its handle_nested_irq() calls. Lockdep caught this on hardware: those calls reach phy_interrupt() for the per-port PHY IRQ lines mapped through this chip, which takes phydev->lock, while phy_attach_direct() and this driver's own indirect PHY access already establish the opposite order (phydev->lock, then priv->bus->mdio_lock) elsewhere. Using them here would close that cycle, so they are not used. regmap_irq_sync_unlock() also has its own init_ack_masked path, used by this chip, which unconditionally does its own regmap_write() to ack currently-masked IRQs; that path has no per-driver hook. Together with the threaded handler's own status read and ack write, these stay unprotected -- a narrower, harder-to-hit gap than the recurring mask sync above -- and will be closed once the switch regmap moves to regmap's own locking in the driver-wide register access cleanup. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/818840879e9cd20f8d568789da29b3474c8f3ab9.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski

net: dsa: mt7530: check command register writes in fdb and vlan cmd

2026-08-07T23:38:58+00:00

mt7530_fdb_cmd() and mt7530_vlan_cmd() start a command by writing the BUSY bit to MT7530_ATC / MT7530_VTCR, then poll for it to clear. mt7530_write() discards the write's return value, so a failed command write leaves BUSY unset and the poll succeeds on its first read, reporting a command that never ran as done -- returning stale FDB data or silently dropping a VLAN table update. Return mt7530_mii_write()'s error from mt7530_write() and check it in both command helpers. Signed-off-by: Daniel Golle Link: https://patch.msgid.link/0e5d65a672313286e5a8ce28a9faba9c8972dbb6.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski

net: dsa: mt7530: check CORE_PLL_GROUP4 access in mt7531_setup()

2026-08-07T23:38:55+00:00

mt7531_setup() reads CORE_PLL_GROUP4 through the MT7531 indirect c45 PHY access, modifies it and writes it back to enable the PHY core PLL, but checks neither the read nor the write. Now that the indirect access functions propagate command-write failures, a failed read returns a negative errno that would be bit-modified and written back into the PLL register, and a failed write-back would go unnoticed. Check both and bail out. The adjacent EEE advertisement writes push a constant value and cannot corrupt state, so they are left as is. Signed-off-by: Daniel Golle Link: https://patch.msgid.link/a7dfe3b66ea6ac1ae7915034de0527060e6ddcd4.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski

net: dsa: mt7530: error out on failed PHY_IAC command writes

2026-08-07T23:38:53+00:00

MT7531_PHY_ACS_ST is only ever set by the command write that precedes each poll in the MT7531 indirect PHY access functions, and that write's return value is discarded. A failed write leaves ACS_ST at 0 from the previous access, so the poll succeeds on its first iteration and the functions return stale IAC contents as if they were fresh PHY data. Check the writes and bail out before polling. Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/c34602e63a20ebbfb97babd145c82832d7a0b523.1785811140.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski