wireguard-linux, branch davem/net

Revert "net: stmmac: propagate PTP addend and system time programming errors"

2026-10-06T01:19:42Z

This reverts commit 232d49dd4b40a666283de9e722899f088ed581b2. Anirudh reports a regression from this change. It is not appropriate for net this late in the release cycle in the first place, so let's revert and revisit in net-next. Reported-by: Anirudh Srinivasan Link: https://lore.kernel.org/CAEev2e8+fr1tJnSErD+2TtLDw5fGJbQOMcM5eefMnLyFUR+m7w@mail.gmail.com Fixes: 232d49dd4b40 ("net: stmmac: propagate PTP addend and system time programming errors") Signed-off-by: Jakub Kicinski

net: airoha: Add retry mechanism to airoha_qdma_set_trtcm_param()

2026-10-06T00:45:01Z

CPU accesses QDMA via the bus. When multiple modules are using the bus simultaneously, CPU access to QDMA may encounter bus timeouts and fails, resulting in QDMA configuration failures and potentially causing packet transmission issues. In order to mitigate the issue, introduce a retry mechanism to airoha_qdma_set_trtcm_param routine in order to ensure the configuration is correctly applied to the hardware. It's enough to try a second time for the TRTCM config to be actually applied to make sure we are not in the middle of bucket handling as it does operate on fixed time slot internally. Fixes: ef1ca9271313b ("net: airoha: Add sched HTB offload support") Signed-off-by: Leto Liu (刘涛) [ improve commit description, drop memory block, apply better loop logic] Signed-off-by: Christian Marangi Link: https://patch.msgid.link/20260930065855.46171-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski

Merge branch 'gve-various-xdp-fixes'

2026-10-06T00:00:07Z

Joshua Washington says: ==================== gve: various XDP fixes This patch series consists of a number of small XDP-related fixes. These changes are split off from https://lore.kernel.org/20260922194533.631387-1-joshwash@google.com in an effort to prevent blocking relatively simple fixes on more complex fixes that will need more feedback to merge. A summary of the changes: 1) fix an issue where XSK buffers that have not been processed are leaked when disabling XSK pools 2) fix an XSK buffer leak when an RX error descriptor comes back from the hardware 3) fix a deadlock introduced by attempting to acquire the netdev lock after it has already been acquired ==================== Link: https://patch.msgid.link/20260930214735.3288780-1-joshwash@google.com Signed-off-by: Jakub Kicinski

gve: fix napi_disable deadlock when attempting to disable XSK pools

2026-10-05T23:59:56Z

When disabling XSK pools, GVE calls the unlocked versions of napi_disable and napi_enable. However, the netdev lock has already been acquired before ndo_bpf is called because GVE supports queue management ops. Calling the unlocked versions of napi_disable/enable results in a deadlock when attempting to disable XSK pools, as the thread attempts to re-acquire a lock it already holds. Update the NAPI calls to use the locked versions. This issue was found in production. Fixes: 606048cbd834 ("net: designate XSK pool pointers in queues as "ops protected"") Cc: stable@vger.kernel.org Reviewed-by: Harshitha Ramamurthy Reviewed-by: Jordan Rhee Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-4-joshwash@google.com Signed-off-by: Jakub Kicinski

gve: fix XSK buffer leak on error descriptor

2026-10-05T23:59:36Z

When the error bit is set in the RX completion descriptor, the buf_state and its attached buffer should be freed. In the case of AF_XDP ZC, the XSK buffer was not freed, leading to a leak. This issue was caught by LLM. Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy") Cc: stable@vger.kernel.org Reviewed-by: Jordan Rhee Reviewed-by: Tim Hostetler Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-3-joshwash@google.com Signed-off-by: Jakub Kicinski

gve: fix XSK buffer leak when rings are stopped

2026-10-05T23:59:18Z

GVE does not free XSK buffers when resetting ring state as a part of stopping queues. This causes all XSK buffers which are posted to the NIC to be leaked. Free XSK buffers attached to an allocated buf_state when stopping rings. This issue was hit in production. Fixes: c1fffc5d66a7 ("gve: implement DQO RX datapath and control path for AF_XDP zero-copy") Cc: stable@vger.kernel.org Reviewed-by: Tim Hostetler Reviewed-by: Jordan Rhee Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20260930214735.3288780-2-joshwash@google.com Signed-off-by: Jakub Kicinski

Merge branch 'net-stmmac-fix-double-vlan-802-1ad-tag-handling'

2026-10-05T23:36:45Z

Ovidiu Panait says: ==================== net: stmmac: Fix double VLAN 802.1ad tag handling Currently, hardware VLAN stripping is broken for 802.1ad tags. vlan_rx_hw() hardcodes ETH_P_8021Q when putting the hardware tag into the skb, rather than using the actual protocol from the packet. Because of this, packets that contain an 802.1ad outer tag are incorrectly passed up the stack as having an 802.1Q tag. This issue was observed on the Renesas RZ/V2H platform (which has a dwmac4 IP), when testing QinQ ping: # DUT ip link add link end0 name end0.100 type vlan proto 802.1ad id 100 ip link add link end0.100 name end0.100.200 type vlan proto 802.1q id 200 ip addr add 172.16.3.2/24 dev end0.100.200 ip link set end0 up ip link set end0.100 up ip link set end0.100.200 up # Peer ip link add link eth0 name eth0.100 type vlan proto 802.1ad id 100 ip link add link eth0.100 name eth0.100.200 type vlan proto 802.1q id 200 ip addr add 172.16.3.1/24 dev eth0.100.200 ip link set eth0 up ip link set eth0.100 up ip link set eth0.100.200 up ping 172.16.3.2 -- FAIL -- Note that this series only fixes the issue on dwmac4. dwxgmac2 has the same issue but I do not have access to hw to test on. Since dwmac4 does not expose the tag type in the RDES3 descriptor, it cannot support hardware S-Tag stripping correctly. This series disables S-tag stripping for it, so the 802.1ad tags are left in place and are handled by the software VLAN path. ==================== Link: https://patch.msgid.link/20260928203441.34876-1-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski

net: stmmac: Disable S-Tag processing on dwmac4

2026-10-05T23:36:45Z

Currently, hardware VLAN stripping is broken for 802.1ad tags. vlan_rx_hw() hardcodes ETH_P_8021Q when putting the hardware tag into the skb, rather than using the actual protocol from the packet. Because of this, packets that contain a 802.1ad outer tag are incorrectly passed up the stack as having an 802.1Q tag. This causes QinQ ping between two hosts to fail. vlan_rx_hw() is shared by dwxgmac2 and dwmac4: on dwxgmac2 the tag type is available in the RDES3 write-back descriptor (the ET_LT field), so the outer tag type can be determined based on that info. However, dwmac4 doesn't seem to provide the tag type. The Length/Type field in RDES3 only indicates whether the packet is single or double-tagged, not which tag type was stripped. Since dwmac4 cannot report the stripped tag type, it cannot support hardware S-Tag stripping correctly. Therefore, restrict the NETIF_F_HW_VLAN_STAG_RX and NETIF_F_HW_VLAN_STAG_FILTER advertisement to dwxgmac2 only. With this, 802.1ad tags are left in place and handled by the software VLAN path. Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-6-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski

net: stmmac: Do not advertise S-VLAN stripping when it is disabled

2026-10-05T23:36:45Z

C-VLAN and S-VLAN tag stripping are both controlled by the EVLS bit, so disabling rx-vlan-offload also disables S-VLAN tag stripping. However, rx-vlan-stag-hw-parse keeps being advertised as enabled: root@rzv2h-evk:~# ethtool -K end1 rx-vlan-offload off root@rzv2h-evk:~# ethtool -k end1 | grep -i vlan rx-vlan-offload: off tx-vlan-offload: off [fixed] rx-vlan-filter: on [fixed] vlan-challenged: off [fixed] tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: on [fixed] rx-vlan-stag-filter: on [fixed] Fix this inconsistency by making NETIF_F_HW_VLAN_STAG_RX follow NETIF_F_HW_VLAN_CTAG_RX. Fixes: 750011e239a5 ("net: stmmac: Add support for HW-accelerated VLAN stripping") Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-5-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski

net: stmmac: Rename double VLAN references to svlan

2026-10-05T23:36:45Z

The ESVL and DOVLTC bits control S-VLAN tag processing and have nothing to do with the double VLAN feature, which only provides a way to process an additional inner VLAN tag. However, the driver code that handles them always refers to "double VLAN", which is unrelated and makes the implementation confusing. The driver does not use any of the inner VLAN tag features, and the networking core does not support offloads for the inner tag anyway. To reduce the confusion regarding S-Tag vs double VLAN handling, rename double -> svlan. No functional change intended. Suggested-by: Joseph Steel Signed-off-by: Ovidiu Panait Reviewed-by: Maxime Chevallier Link: https://patch.msgid.link/20260928203441.34876-4-ovidiu.panait.rb@renesas.com Signed-off-by: Jakub Kicinski