kernel/git/next/linux-next.git/drivers/net/dsa, branch master

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

2026-09-10T22:14:05+00:00

Cross-merge networking fixes after downstream PR (net-7.3-rc3). Conflicts: drivers/net/dsa/mt7530.c 3c18e3c9a54e ("net: dsa: mt7530: populate lpi_interfaces to fix EEE support") 10d9d8328e8a ("net: dsa: mt7530: replace mt7530_read with regmap_read") Adjacent changes: drivers/net/bonding/bond_alb.c 1746ef2e2df2 ("bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()") 4cef95f72bbd ("bonding: fix u32 overflow in compute_gap()") Signed-off-by: Jakub Kicinski

Merge tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-09-10T21:07:48+00:00

Pull networking fixes from Jakub Kicinski: "Nothing too exciting, usual stream of fixes. Including fixes from Netfilter, Bluetooth and WPAN. Current release - new code bugs: - Bluetooth: hci_sync: fix not setting CE length properly - eth: enic: match mailbox replies to request numbers Previous releases - regressions: - tunnels: drop stale dst when building an ICMP error for PMTUD - ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() (bug in the rtnl_lock -> RCU conversion) - eth: bnxt_en: - fix crashes on Thor2 due to OOB coalescing buffer accesses - prevent queue stop with deferred completions Previous releases - always broken: - eth: - ice: don't dereference pointers from TP_printk() - fix OOB writes on ethtool flow rule dump in 3 drivers - mlx5: fix FEC configuration with RS_544_514_INTERLEAVED_QUAD - dsa: tag_brcm: legacy FCS: request needed tailroom Misc: - net: cap tx_queue_len at S16_MAX to prevent oversized ring alloc - ipv6: flowlabel: cap duplicate leases per socket" * tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (164 commits) selftests: tc-testing: test action batch failure cleanup net/sched: act_api: release all action references on NEWACTION failure openvswitch: fix wrong flag value in get_ipv6_ext_hdrs() ipmr: account multicast table and route memory net: phy: dp83td510: handle the active-high LED polarity mode net: macb: initialize PTP state before registering clock net: hsr: enable promiscuous mode on interlink port with fwd offload ipv6: fix fib6 walker UAF on seq stop net: stmmac: fix TX descriptor availability check for TSO traffic net/rds: fix tcp stream corruption with large pages net: mana: restore the XDP program pointer when pre-allocation fails net: phy: dp83867: handle the active-high LED polarity mode octeontx2-af: fix PF/CGX debugfs PCI bus lookup net: net_failover: Fix the deadlock in net_failover_slave_name_change() net: phy: mediatek-ge: disable EEE on the MT7530 PHY tcp: reject non zerocopy devmem tx net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support net: dsa: mt7530: populate lpi_interfaces to fix EEE support net: hinic: fix mailbox segment buffer overflow net: sun4i-emac: fix missing of_node_put() for phy_node ...

net: dsa: mt7530: populate lpi_interfaces to fix EEE support

2026-09-10T11:31:28+00:00

phylink_create() decides once and for all that a MAC supports managed EEE, and it requires the tx_lpi ops plus non-empty lpi_capabilities and lpi_interfaces. mt753x_phylink_get_caps() leaves lpi_interfaces empty. So ever since the conversion to phylink managed EEE, ethtool has answered "Not supported" on every mt753x port, and phy_disable_eee() has locked userspace out of turning EEE on. That undoes what commit 06dfcd4098cf ("net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards") arranged: EEE off by default, but reachable with ethtool. Leave the speeds above 1 Gbps out of both bitmaps. PMCR folds SPEED_2500 and SPEED_10000 onto PMCR_FORCE_SPEED_1000, so PMCR_FORCE_EEE1G would govern LPI on such a link, and that is unvalidated rather than known unsupported: MediaTek's SDK driver sets the EEE force bits for 100 Mbps and 1 Gbps only, and the unit of the wakeup timers is undocumented with the port clock at 2.5 times the rate. LPI stays off until userspace enables it, but the EEE advertisement of a PHY that advertises it out of reset comes back, since phylink stops force-clearing it. Fixes: 9cf21773f535 ("net: dsa: mt7530: convert to phylink managed EEE") Signed-off-by: Aleksei Sviridkin Link: https://patch.msgid.link/20260903123644.23800-2-f@lex.la Signed-off-by: Paolo Abeni

net: dsa: microchip: enable the SGMII port of the KSZ9897S

2026-09-10T01:41:06+00:00

The KSZ9897 has an SGMII/1000BASE-X capable port 7, but its chip_info entry never set .sgmii_port. ksz_has_sgmii_port() is therefore false, ksz9477_pcs_create() is never called and ksz9477_phylink_mac_select_pcs() returns NULL for port 7, so a phy-mode = "sgmii" or "1000base-x" link on that port cannot come up. Only the KSZ9897S has that port; the KSZ9897R has a second RGMII port instead. Both report chip ID 0x00989700, so the port cannot be enabled from the chip ID alone, and enabling it unconditionally breaks the KSZ9897R badly: ksz9477_setup() propagates the failure of xpcs_create_pcs_mdiodev() on a part without an XPCS, so the switch as a whole stops probing. The variants do differ in the read-only bit 7 of the port 7 XMII control 0 register, which reads one on the KSZ9897S and zero on the KSZ9897R. Compare the KSZ9897S data sheet DS00002394C section 5.2.4.1 with the KSZ9897R data sheet DS00002330D section 5.2.3.1. Read that bit in ksz_switch_register() and use it to select a KSZ9897S chip_data entry, which is the KSZ9897 one plus .sgmii_port = 7, with port 7 no longer marked as supporting MII, RMII and RGMII. On the KSZ9897S that port is permanently an SGMII port and only its differential pairs are brought out, so advertising the xMII modes on it would let phylink accept a mode the driver never programs: ksz_phylink_need_config() skips the XMII control registers for the SGMII port. The KSZ9477, which also has SGMII on port 7, is described the same way. See DS00002394C section 4.11. KSZ9897S_CHIP_ID selects that chip_data entry and nothing else. dev->chip_id keeps the KSZ9897 chip ID that both parts report, so no other chip ID comparison has to know about the variant, ksz_check_device_id() is unchanged, and a device tree naming the KSZ9897 keeps matching whichever part is fitted. No binding change is needed and existing device trees keep working. Tested on a KSZ9897S with a 1000BASE-LX fibre SFP on port 7: bit 7 of the port 7 XMII control 0 register reads one, the switch is identified as a KSZ9897S and the PCS is created. The port advertises 1000baseX/Full, clause 37 in-band autonegotiation completes against the link partner, and the link comes up at 1Gbps/full duplex and passes traffic. Suggested-by: Nicolai Buchwitz Suggested-by: Jerry Ray Suggested-by: Tristram Ha Signed-off-by: Tapio Reijonen Reviewed-by: Linus Walleij Link: https://patch.msgid.link/20260904-ksz9897-sgmii-port-v5-1-9bd4a0381aa8@vaisala.com Signed-off-by: Jakub Kicinski

net: dsa: lantiq_gswip: fix GSWIP_MDIO_PHY_FCONTX_EN value

2026-09-10T00:59:33+00:00

Per the GSW145 data sheet, the FCONTX (bits 8:7) and FCONRX (bits 6:5) flow-control fields of the PHY_ADDR_n register both encode 00 = AUTO, 01 = EN, 10 = reserved, 11 = DIS. GSWIP_MDIO_PHY_FCONTX_EN was 0x0100, i.e. field value 10 (the reserved encoding), instead of 0x0080 (01 = EN); FCONRX_EN is already 0x0020 (01). Enabling tx flow control therefore wrote the reserved value. Set FCONTX_EN to 0x0080. The register is shared by all supported parts. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Jan Havran (Advantech Czech) Reviewed-by: Daniel Golle Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260907134818.16670-4-havran.jan@email.cz Signed-off-by: Jakub Kicinski

net: dsa: lantiq_gswip: handle SPEED_2500 in gswip_port_set_speed()

2026-09-10T00:59:02+00:00

The mxl-gsw1xx driver advertises 2500BASE-X on its SGMII port (via supports_2500m and gsw1xx_phylink_get_caps()), but the shared gswip_port_set_speed() has no SPEED_2500 case: at 2.5G every field keeps its initializer, so mdio_phy = 0 pins the MDIO speed override to 10 Mbps and no data passes. At the MAC/MDIO level 2500BASE-X is identical to 1 Gbps (same wide GMII datapath, same speed override); the rate itself is set in the PCS and SerDes, not here. This matches the boot loader's PHY_ADDR_4 = 0x32A4 for the 2.5G strap ("1 Gbps or above"), whose SPEED field is GSWIP_MDIO_PHY_SPEED_G1 (the field has no encoding above G1). Share the SPEED_1000 arm via a stacked case label. Its mii_cfg value is a no-op for 2.5G: gswip_mii_mask_cfg() writes it only for the RGMII port (mii_cfg[SGMII port] == -1), which cannot reach 2.5G anyway. Cc: stable+noautosel@kernel.org # never worked Signed-off-by: Jan Havran (Advantech Czech) Reviewed-by: Daniel Golle Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260907134818.16670-3-havran.jan@email.cz Signed-off-by: Jakub Kicinski

net: dsa: mxl-gsw1xx: set SerDes NCO rate before SGMII reset

2026-09-10T00:58:50+00:00

gsw1xx_pcs_config() releases the SGMII shell from reset via gsw1xx_pcs_reset() and only afterwards programs NCO_CTRL to select the SerDes clock rate (1G NCO1 vs 2.5G NCO2). The chip boot loader uses the other order: NCO_CTRL -> RST_REQ -> SGMII_PHY_HWBU_CTRL (GSW145 data sheet, section 3.2.8, table 13). Program NCO_CTRL before gsw1xx_pcs_reset() to follow that order. On an Armada 7040 board driving a GSW145 whose switch comes up at 2.5G (pin strap PS_SUBTYPE_MD[2] = 1, pin LED42 / PS1 bit 14; GSW145 data sheet tables 23 and 25), a 1 Gbps SGMII link only carried traffic with this change. It matters when the rate the switch is left at - by the straps or by the boot loader - differs from the rate the driver selects, which is likely why it has not been seen before. Cc: stable+noautosel@kernel.org # never worked Signed-off-by: Jan Havran (Advantech Czech) Reviewed-by: Daniel Golle Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260907134818.16670-2-havran.jan@email.cz Signed-off-by: Jakub Kicinski

net: dsa: motorcomm: Handle degenerated blink delays

2026-09-10T00:56:43+00:00

The LED core defines delay_on == 0 as steady off and delay_off == 0 as steady on, which was treated as a blink in our LED driver. Fix it. Fixes: 9af9a8168213 ("net: dsa: motorcomm: Add LED support") Signed-off-by: David Yang Link: https://patch.msgid.link/20260904134752.635133-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski

net: dsa: sja1105: Remove comma after sentinel-entry in match-table

2026-09-07T23:56:16+00:00

Since sentinel is the last entry and we do not expect further entries following it, remove the comma. Signed-off-by: Siddharth Vadapalli Link: https://patch.msgid.link/20260904043724.2955444-24-s-vadapalli@ti.com Signed-off-by: Jakub Kicinski

net: dsa: rzn1_a5psw: Remove comma after sentinel-entry in match-table

2026-09-07T23:56:06+00:00

Since sentinel is the last entry and we do not expect further entries following it, remove the comma. Reviewed-by: Geert Uytterhoeven Signed-off-by: Siddharth Vadapalli Link: https://patch.msgid.link/20260904043724.2955444-23-s-vadapalli@ti.com Signed-off-by: Jakub Kicinski