wireguard-linux/drivers/net/ethernet/realtek, branch stable

r8169: disable EEE on RTL8168h/8111h

2026-10-01T00:18:00Z

Force EEE off on the RTL8168h/8111h (RTL_GIGA_MAC_VER_46) at PHY connect with phy_disable_eee(). Commit 202fef9bbbf5 ("net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path") made EEE actually advertise on the generic Realtek PHY; the write had been a no-op before. On the RTL8168h that un-masks a latent defect: once EEE negotiates, RX silently stalls after ~7-20 minutes. The carrier stays up, no counter or dmesg moves, and only "ip link set down/up" recovers it; disabling EEE keeps the link stable. Root-causing the RTL8168h LPI/RX path needs hardware not available now, so disable EEE for this version. Use phy_disable_eee() rather than dropping the version from rtl_supports_eee(): the latter also skips rtl_enable_tx_lpi(), whose disable branch clears the MAC TX-LPI bits (ERI 0x1b0[1:0]) on link up. rtl_hw_start_8168h_1() does not clear them (the RTL8402/RTL8106e init does), so a warm reboot from an EEE-active state could otherwise leave TX-LPI asserted while the PHY no longer negotiates EEE. Keeping the version EEE-capable preserves that clear path. This also covers the RTL8168M, which shares RTL_GIGA_MAC_VER_46. Reported-by: Dennis Piecha Closes: https://lore.kernel.org/all/353419280.954808.1790290283530@mail.yahoo.com/ Fixes: 202fef9bbbf5 ("net: phy: realtek: fix EEE advertisement write on the internal PHY MMD path") Cc: stable@vger.kernel.org Signed-off-by: Oleksij Rempel Link: https://patch.msgid.link/20260925071040.2137178-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski

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

2026-08-18T17:42:41Z

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

8139cp: fix Rx and Tx not being disabled in cp_suspend

2026-08-18T10:02:11Z

On QEMU rtl8139 model, frames that arrive while the interface is suspended still end up in the stack after resume. With pm_test=devices, which keeps devices suspended for 5s, 200 frames sent to interface during that time and 50 frames after resume, eth0 reports 113 received frames. cp_suspend() is supposed to stop receiver and the transmitter, but the mask is wrong: (~RxOn | ~TxOn) is ~0, nothing is cleared and Cmd still reads 0x0d when cp_suspend() returns. Use ~(RxOn | TxOn) so both bits are actually cleared. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Karl Mehltretter Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260817043057.20099-1-kmehltretter@gmail.com Signed-off-by: Paolo Abeni

r8169: keep LED device name valid after setup

2026-08-17T17:29:58Z

rtl8168_setup_ldev() and rtl8125_setup_led_ldev() build the LED device name in a stack buffer and assign it to led_cdev->name. The LED class device registration path reads led_cdev->name after it has been assigned, and struct led_classdev stores the name as part of the LED class device state. Do not keep a pointer to a setup function's stack buffer there. Store the name in struct r8169_led_classdev instead, so it remains valid for the lifetime of the LED class device. Signed-off-by: Zhixing Chen Reviewed-by: Andrew Lunn Link: https://patch.msgid.link/20260813100711.14724-1-running910@gmail.com Signed-off-by: Jakub Kicinski

r8169: give RTL_GIGA_MAC_VER_EXTENDED a distinct value

2026-08-13T00:51:37Z

RTL_GIGA_MAC_VER_EXTENDED implicitly follows RTL_GIGA_MAC_VER_LAST = RTL_GIGA_MAC_NONE - 1, so it has the same value as RTL_GIGA_MAC_NONE. rtl_init_one() therefore sends unknown chips through extended detection. If TX_CONFIG_V2 reads as zero, they are misidentified as RTL9151AS instead of being rejected. Give RTL_GIGA_MAC_VER_EXTENDED a distinct value. It is only a detection marker and is never stored in tp->mac_version. Found by Clang's -Wduplicate-enum and verified with a QEMU stub. Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path Signed-off-by: Karl Mehltretter Link: https://patch.msgid.link/20260808101941.57666-1-kmehltretter@gmail.com Signed-off-by: Jakub Kicinski

rtase: fix double free of multi-frag skb on DMA map failure

2026-07-28T01:16:42Z

In rtase_start_xmit(), when the head buffer DMA mapping fails after rtase_xmit_frags() has mapped all fragments, the error path clears the fragment descriptors with rtase_tx_clear_range(), which frees the skb through the last-frag slot and accounts tx_dropped. Control then falls through to the common error label, which frees the same skb a second time and counts it again. Return right after clearing the fragments when the skb owns frags; the no-frag case still drops through and frees the head skb once. Fixes: d6e882b89fdf ("rtase: Implement .ndo_start_xmit function") Signed-off-by: Yun Lu Reviewed-by: Jacob Keller Reviewed-by: Justin Lai Link: https://patch.msgid.link/20260721023836.6691-1-luyun_611@163.com Signed-off-by: Jakub Kicinski

rtase: Workaround for TX hang caused by hardware packet parsing

2026-07-21T18:30:20Z

The hardware performs packet parsing before packet transmission. Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX hang because the hardware parser expects additional protocol header data that is not present in the packet. The hardware performs additional PTP parsing on UDP packets identified by destination ports 319/320 at the expected UDP destination port offset. If such a packet has transport data smaller than RTASE_MIN_PAD_LEN, the hardware parser expects additional packet data and may trigger a TX hang. To avoid these hardware issues, the driver applies the following workarounds. Drop malformed packets that may trigger this hardware issue before transmission. For IPv4 non-initial fragments, the hardware does not check the fragment offset before parsing the expected transport header location. As a result, these packets are still subject to transport header parsing even though they do not contain a transport header. If the transport data is shorter than the minimum transport header required by the hardware parser, pad the transport data to the minimum transport header length required by the hardware parser. Packets that also match the hardware PTP parsing conditions continue to follow the corresponding workaround. For IPv6 fragmented packets, neither of the above hardware issues occurs because the hardware only continues packet parsing when the IPv6 Base Header Next Header field directly indicates UDP. Packets carrying a Fragment Header do not continue through the subsequent packet parsing stages. For packets identified for hardware PTP parsing, pad the transport data so it reaches RTASE_MIN_PAD_LEN before transmission. Fixes: d6e882b89fdf ("rtase: Implement .ndo_start_xmit function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260709103456.83789-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski

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

2026-06-04T22:29:04Z

Cross-merge networking fixes after downstream PR (net-7.1-rc7). Silent conflicts: net/wireless/nl80211.c cb9959ab5f99 ("wifi: cfg80211: enforce HE/EHT cap/oper consistency") a384ae969902 ("wifi: cfg80211: move AP HT/VHT/... operation to beacon info") https://lore.kernel.org/aiGJDaHV4UlCexIQ@sirena.org.uk Conflicts: drivers/net/wireless/intel/iwlwifi/mld/ap.c a342c99cb70d ("wifi: iwlwifi: mld: honor BSS_CHANGED_BEACON_ENABLED") 9bf1b409afc7 ("wifi: iwlwifi: mld: send tx power constraints before link activation") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk drivers/net/wireless/intel/iwlwifi/pcie/drv.c 093305d801fa ("wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used") e2323929a68a ("wifi: iwlwifi: pcie: add debug print for resume flow if powered off") https://lore.kernel.org/ah2bfedhV45ZxMO8@sirena.org.uk Adjacent changes: drivers/net/ethernet/airoha/airoha_eth.c b38cae85d1c4 ("net: airoha: Fix use-after-free in metadata dst teardown") ec6c391bcca7 ("net: airoha: Introduce airoha_gdm_dev struct") drivers/net/ethernet/microchip/lan743x_main.c 8173d22b211f ("net: lan743x: permit VLAN-tagged packets up to configured MTU") e3c6508a46f5 ("net: lan743x: avoid netdev-based logging before netdev registration") Signed-off-by: Jakub Kicinski

rtase: Avoid sleeping in get_stats64()

2026-06-04T15:52:24Z

The .ndo_get_stats64 callback must not sleep because it can be called when reading /proc/net/dev. rtase_get_stats64() calls rtase_dump_tally_counter(), which polls the tally counter dump bit with read_poll_timeout(). This may sleep while waiting for the hardware counter dump to complete. Use read_poll_timeout_atomic() instead to avoid sleeping in the get_stats64() path. Fixes: 079600489960 ("rtase: Implement net_device_ops") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Link: https://patch.msgid.link/20260603061816.31356-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski

rtase: Reset TX subqueue when clearing TX ring

2026-06-04T15:35:30Z

rtase_tx_clear() clears the TX ring and resets the ring indexes. However, the TX queue state and BQL accounting are not reset at the same time. This may leave __QUEUE_STATE_STACK_XOFF asserted after rtase_sw_reset(), preventing new TX packets from being scheduled. Reset the TX subqueue when clearing the TX ring so the TX queue state and BQL accounting are restored together. Fixes: 5a2a2f15244c ("rtase: Implement the rtase_down function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260602114659.12335-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski