linux/drivers/net/ethernet/stmicro, branch master

net: stmmac: enable RPS and RBU interrupts

2026-04-13T21:34:38Z

Enable receive process stopped and receive buffer unavailable interrupts, so that the statistic counters can be updated. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1wBBaR-0000000GZHR-1dbM@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski

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

2026-04-09T20:20:59Z

Cross-merge networking fixes after downstream PR (net-7.0-rc8). Conflicts: net/ipv6/seg6_iptunnel.c c3812651b522f ("seg6: separate dst_cache for input and output paths in seg6 lwtunnel") 78723a62b969a ("seg6: add per-route tunnel source address") https://lore.kernel.org/adZhwtOYfo-0ImSa@sirena.org.uk net/ipv4/icmp.c fde29fd934932 ("ipv4: icmp: fix null-ptr-deref in icmp_build_probe()") d98adfbdd5c01 ("ipv4: drop ipv6_stub usage and use direct function calls") https://lore.kernel.org/adO3dccqnr6j-BL9@sirena.org.uk Adjacent changes: drivers/net/ethernet/stmicro/stmmac/chain_mode.c 51f4e090b9f8 ("net: stmmac: fix integer underflow in chain mode") 6b4286e05508 ("net: stmmac: rename STMMAC_GET_ENTRY() -> STMMAC_NEXT_ENTRY()") Signed-off-by: Jakub Kicinski

net: stmmac: dwmac-motorcomm: fix eFUSE MAC address read failure

2026-04-08T01:21:00Z

This patch fixes an issue where reading the MAC address from the eFUSE fails due to a race condition. The root cause was identified by comparing the driver's behavior with a custom U-Boot port. In U-Boot, the MAC address was read successfully every time because the driver was loaded later in the boot process, giving the hardware ample time to initialize. In Linux, reading the eFUSE immediately returns all zeros, resulting in a fallback to a random MAC address. Hardware cold-boot testing revealed that the eFUSE controller requires a short settling time to load its internal data. Adding a 2000-5000us delay after the reset ensures the hardware is fully ready, allowing the native MAC address to be read consistently. Fixes: 02ff155ea281 ("net: stmmac: Add glue driver for Motorcomm YT6801 ethernet controller") Reported-by: Georg Gottleuber Closes: https://lore.kernel.org/24cfefff-1233-4745-8c47-812b502d5d19@tuxedocomputers.com Signed-off-by: Johan Alvarado Reviewed-by: Yao Zi Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/fc5992a4-9532-49c3-8ec1-c2f8c5b84ca1@smtp-relay.sendinblue.com Signed-off-by: Jakub Kicinski

net: stmmac: Fix PTP ref clock for Tegra234

2026-04-03T23:02:21Z

Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not 0 before configuring timestamping") was added the following error is observed on Tegra234: ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed It turns out that the Tegra234 device-tree binding defines the PTP ref clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now exposes this and that the PTP clock is not configured correctly. In order to update device-tree to use the correct 'ptp_ref' name, update the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using 'ptp-ref' if this clock name is present. Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support") Signed-off-by: Jon Hunter Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260401102941.17466-2-jonathanh@nvidia.com Signed-off-by: Jakub Kicinski

net: stmmac: qcom-ethqos: set clk_csr

2026-04-03T21:39:04Z

The clocks for qcom-ethqos return a rate of zero as firmware manages their rate. According to hardware documentation, the clock which is fed to the slave AHB interface can range between 50 to 100MHz for non-RGMII and 30 to 75MHz for boards with a RGMII interfaces. Currently, stmmac uses an undefined divisor value. Instead, use STMMAC_CSR_60_100M which will mean we meet IEEE 802.3 specification since this will generate: 714kHz @ 30MHz 1.19MHz @ 50MHz 1.79MHz @ 75MHz 2.42MHz @ 100MHz This gives MDC rates within the IEEE 802.3 specification, although the 30MHz case is particularly slow. Selecting the next lowest divisor, STMMAC_CSR_35_60M, which is /26 will give: 1.15MHz @ 30MHz 1.92MHz @ 50MHz 2.88MHz @ 75MHz (exceeding 802.3 spec) 3.85MHz @ 100MHz (exceeding 802.3 spec) Unfortunately, this divisor makes the upper bound of both ranges exeed the IEEE 802.3 specification, and thus we can not use it without knowing for certain what the current CSR clock rate actually is. So, STMMAC_CSR_60_100M is the best fit for all boards based on the information provided thus far. Link: https://lore.kernel.org/r/acGhQ0oui+dVRdLY@oss.qualcomm.com Link: https://lore.kernel.org/r/acw1habUsiSqlrky@oss.qualcomm.com Reviewed-by: Mohd Ayaan Anwar Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w8JKr-0000000EdLC-41Bt@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski

stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig

2026-04-03T21:37:31Z

There are already 'if STMMAC_ETH' and 'STMMAC_PLATFORM' conditions wrapping these config options, making the 'depends on' statements duplicate dependencies (dead code). I propose leaving the outer 'if STMMAC_PLATFORM...endif' and 'if STMMAC_ETH...endif' conditions, and removing the individual 'depends on' statements. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha Reviewed-by: Russell King (Oracle) Link: https://patch.msgid.link/20260402145858.240231-1-julianbraha@gmail.com Signed-off-by: Jakub Kicinski

net: stmmac: fix integer underflow in chain mode

2026-04-03T01:28:10Z

The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward. Fixes: 286a83721720 ("stmmac: add CHAINED descriptor mode support (V4)") Cc: stable@vger.kernel.org Signed-off-by: Tyllis Xu Link: https://patch.msgid.link/20260401044708.1386919-1-LivelyCarpet87@gmail.com Signed-off-by: Jakub Kicinski

net: stmmac: move "TSO supported" message to stmmac_set_gso_features()

2026-04-02T18:28:20Z

Move the "TSO supported" message to stmmac_set_gso_features() so that we group all probe-time TSO stuff in one place. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w7pu8-0000000Eau5-3Zne@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski

net: stmmac: check txpbl for TSO

2026-04-02T18:28:20Z

Documentation states that TxPBL must be >= 4 to allow TSO support, but the driver doesn't check this. TxPBL comes from the platform glue code or DT. Add a check with a warning if platform glue code attempts to enable TSO support with TxPBL too low. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w7pu3-0000000Eatz-39ts@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski

net: stmmac: add warning when TSO is requested but unsupported

2026-04-02T18:28:20Z

Add a warning message if TSO is requested by the platform glue code but the core wasn't configured for TSO. Signed-off-by: Russell King (Oracle) Link: https://patch.msgid.link/E1w7pty-0000000Eatt-2TjZ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski