summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2026-06-09wifi: mt76: mt7925: sync MT7927 BSS band assignmentSean Wang5-0/+71
MT7927 needs DBDC enabled and uses a fixed firmware band assignment for 2.4GHz and 5/6GHz BSS contexts. Reprogram the STA dev context when the channel context is assigned so the firmware sees the updated band_idx before the BSS is used. This avoids stale band programming after band changes. Co-developed-by: Javier Tia <floss@jetm.me> Signed-off-by: Javier Tia <floss@jetm.me> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-18-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt792x: add MT7927-specific PCIe DMA supportSean Wang4-3/+113
Add the MT7927-specific PCIe DMA queue layout and local DMA setup, including the extra RX ring and WFDMA/prefetch programming. MT7927 does not follow the mt7925 DMA configuration, so provide a separate DMA init path while reusing the existing common queue setup. This keeps the chip-specific changes local and prepares the driver for later MT7927 enablement without affecting existing devices. Co-developed-by: Javier Tia <floss@jetm.me> Signed-off-by: Javier Tia <floss@jetm.me> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-17-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: switch DMA init to common mt792x queue helpersSean Wang2-55/+48
Convert mt7925 DMA init to use the common mt792x queue allocation helper and isolate the mt7925-specific prefetch/WFDMA setup. This removes duplicated DMA setup code and prepares the path for follow-up chip-specific DMA support with smaller deltas. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-16-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt792x: factor out common DMA queue allocationSean Wang2-0/+75
The mt792x PCIe DMA setup uses the same standard queue allocation sequence for data, MCU, firmware download and RX rings. Factor this part out into a small common helper so later chip support can reuse the existing flow without duplicating the queue setup logic. This keeps the common DMA skeleton in one place and makes follow-up chip-specific DMA changes smaller and easier to review. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-15-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt792x: add MT7927 WFSYS reset supportSean Wang2-1/+67
Add a dedicated MT7927 WFSYS reset path in mt792x_wfsys_reset(). Unlike the existing connac2/connac3 reset flow that toggles the WFSYS software reset bit and waits for init-done, MT7927 reset is driven through CBInfra and requires polling ROMCODE_INDEX until the MCU returns to the idle value after reset. Keep this dormant for now: no MT7927 PCI IDs are added by this patch, so it only prepares the reset logic without making the driver bind to MT7927 hardware yet. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-14-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: connac: tolerate inactive BSS deactivationSean Wang3-3/+35
Firmware may return wlan_failure when deactivating a BSS that is already inactive. This is a valid teardown case and should not fail the remove path. Keep activation failures unchanged since they still indicate that firmware failed to create or activate the BSS state. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-13-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: use link-specific removal for non-MLD STASean Wang1-6/+6
Use the default link removal path for non-MLD STA instead of the multi-link flow. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-12-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: connac: replace is_mt7925() with is_connac3()Sean Wang5-7/+12
Use is_connac3() instead of is_mt7925() to avoid confusion when more chips join. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-11-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927Javier Tia2-3/+6
Disable PCIe ASPM unconditionally for MT7927. The CONNINFRA power domain and WFDMA register access are unreliable with PCIe L1 active, causing throughput to drop from 1+ Gbps to ~200 Mbps. Disable runtime PM and deep sleep for MT7927. The combo chip shares a CONNINFRA power domain between WiFi (PCIe) and BT (USB). SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT firmware, requiring a full power cycle to recover. PM enablement will be addressed in a follow-up once safe power state transitions are determined. Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-10-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: use irq_map for chip-specific interrupt handlingJavier Tia3-3/+26
The mac_reset and resume paths use the hardcoded MT_INT_RX_DONE_ALL constant (bits 0-2) to re-enable RX interrupts. This is correct for MT7925 (RX rings 0, 1, 2) but wrong for chips using different ring indices. Define a per-chip irq_map with the correct RX interrupt enable bits and replace hardcoded MT_INT_RX_DONE_ALL with irq_map field reads in the resume and mac_reset paths. Add the MT7927 irq_map with interrupt bits matching its RX ring layout (rings 4, 6, 7), selected at probe time based on PCI device ID. This ensures the correct interrupt bits are enabled regardless of the chip variant. Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-9-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: add MT7927 firmware pathsJavier Tia2-0/+8
Add firmware path definitions for MT7927 WiFi firmware (WIFI_RAM_CODE and PATCH_MCU) and the corresponding MODULE_FIRMWARE declarations. Add MT7927 cases to mt792x_ram_name() and mt792x_patch_name() so the driver loads the correct firmware for the 0x7927 chip ID. PCI device table entries are deferred to a later patch to allow infrastructure setup before device enablement. Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-8-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: add MT7927 chip ID helpersJavier Tia1-1/+7
The MediaTek MT7927 (Filogic 380) combo chip uses MT7927 WiFi silicon that is architecturally compatible with MT7925. Extend is_mt7925() to match chip ID 0x7927, and add is_mt7927() for code paths that need MT7927-specific handling. Also add 0x7927 to is_mt76_fw_txp() to match MT7925's TXP format. Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-7-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz bandJavier Tia2-1/+26
mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80 and BW = 160, but never sets BW = 320. This means iw phy shows no 320MHz MCS map entries even though the hardware supports 320MHz operation in the 6GHz band. Add the missing 320MHz capability bits for 6GHz: - PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ - PHY_CAP1: beamformee SS for 320MHz - PHY_CAP2: sounding dimensions for 320MHz - PHY_CAP6: MCS15 support for 320MHz width - MCS/NSS: populate bw._320 maps for 6GHz band Introduce is_320mhz_supported() to gate 320MHz on MT7927 only, since MT7925 does not support 320MHz operation. Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-6-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_recJavier Tia1-0/+1
The sta_rec_eht structure has a mcs_map_bw320 field, and the channel width mapping includes NL80211_CHAN_WIDTH_320, but the 320MHz MCS/NSS map was never copied from the station's EHT capabilities to the MCU TLV. This prevents negotiation of 320MHz channel width even when both the hardware and firmware advertise support for it. Add the missing memcpy for the 320MHz MCS map, matching the existing pattern for BW20, BW80, and BW160. Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-5-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXSJavier Tia1-0/+9
The RX vector (RXV) and TX status (TXS) parsing in mac.c lack handling for 320MHz channel width. When the hardware reports 320MHz in the bandwidth field, mt7925_mac_fill_rx_rate() returns -EINVAL and mt7925_mac_add_txs_skb() records no bandwidth stats. Add IEEE80211_STA_RX_BW_320 cases to both functions. The RXV parser also handles BW_320+1 since the hardware can report 320MHz in two adjacent encoding positions. Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-4-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlvJavier Tia1-0/+4
bss_rlm_tlv() in mt7925_mcu_bss_rlm_tlv() has no case for NL80211_CHAN_WIDTH_320. When associated to a 320MHz BSS, the switch falls through to default and sends bw=0 (CMD_CBW_20MHZ) to firmware via BSS_RLM TLV. Firmware then configures the RX radio for 20MHz and cannot decode the AP's 320MHz frames, resulting in complete data path failure at 320MHz. Add the missing NL80211_CHAN_WIDTH_320 case with CMD_CBW_320MHZ and center_chan2. Tested on ASUS RT-BE92U: 320MHz throughput goes from 0 Mbps to 841 Mbps (iperf3 -t30 -P8), PHY 4803 Mbps EHT-MCS11. Reported-by: 张旭涵 <Loong.0x00@gmail.com> Closes: https://github.com/openwrt/mt76/issues/927 Tested-by: 张旭涵 <Loong.0x00@gmail.com> Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_linksJavier Tia1-2/+2
In the error path of mt7925_change_vif_links(), the free: label iterates over link_ids to clean up, but compares against `mconf` and `mlink` which hold stale values from the last loop iteration rather than the current link_id being freed. Use array-indexed access (mconfs[link_id] / mlinks[link_id]) to compare against the correct per-link pointers. Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links") Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7996: Fix NULL pointer dereference in mt7996_init_tx_queues()Lorenzo Bianconi1-1/+1
When MT76_NPU and CONFIG_NET_MEDIATEK_SOC_WED are enabled and mt76 detects properly the Airoha NPU SoC, mt7996_init_tx_queues() will dereference a NULL WED pointer. Fix the issue by always passing the WED pointer from mt7996_dma_init(). Fixes: cd7951f242a7 ("wifi: mt76: mt7996: Integrate MT7990 dma configuration for NPU") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260418-mt7996-dma-init-npu-fix-v1-1-6b8dcffbcb57@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: add Netgear A8500 USB device IDDevin Wittmayer1-0/+3
Add USB device ID for the Netgear A8500 (0846:9050) which uses the mt7925 chipset. Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Link: https://patch.msgid.link/20260527144735.10254-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7996: add missing max_remain_on_channel_durationFelix Fietkau3-2/+2
Having this unset breaks remain-on-channel and mgmt TX. Move setting it to mt76 core to keep it in one place. Fixes: 69d54ce7491d0 ("wifi: mt76: mt7996: switch to single multi-radio wiphy") Link: https://patch.msgid.link/20260324154904.2555603-2-nbd@nbd.name Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7996: fix out-of-bounds array access during hardware restartFelix Fietkau5-25/+43
During hardware restart, link_id can be IEEE80211_LINK_UNSPECIFIED, causing an out-of-bounds array access on msta->link[]. Add mt7996_sta_link() and mt7996_sta_link_protected() helper functions for accessing sta links with proper RCU handling and bounds checking. Use them for any sta link RCU access. Reported-by: Chad Monroe <chad@monroe.io> Link: https://patch.msgid.link/20260324154904.2555603-1-nbd@nbd.name Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt7601u: drop redundant device referenceJohan Hovold1-3/+0
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260430083335.215239-6-johan@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt792xu: drop redundant device referenceJohan Hovold3-5/+0
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260430083335.215239-5-johan@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76x2u: drop redundant device referenceJohan Hovold1-4/+0
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260430083335.215239-4-johan@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76x0u: drop redundant device referenceJohan Hovold1-3/+0
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260430083335.215239-3-johan@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: drop redundant device referenceJohan Hovold1-3/+0
Driver core holds a reference to the USB interface and its parent USB device while the interface is bound to a driver and there is no need to take additional references unless the structures are needed after disconnect. Drop the redundant device reference to reduce cargo culting, make it easier to spot drivers where an extra reference is needed, and reduce the risk of memory leaks when drivers fail to release it. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260430083335.215239-2-johan@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_linkRajat Gupta1-1/+1
mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree() after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents future RCU readers from obtaining the pointer -- it does not wait for existing readers that already hold it via rcu_dereference. The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer via rcu_dereference just before the NULL assignment, it will dereference freed memory after the kfree. struct mt76_vif_link already contains an rcu_head field that is unused at this free site -- a developer oversight, since the adjacent kfree_rcu_mightsleep call for rx_sc in the same function shows the pattern was understood. Replace kfree(mlink) with kfree_rcu(mlink, rcu_head). Fixes: a8f424c1287c ("wifi: mt76: add multi-radio remain_on_channel functions") Signed-off-by: Rajat Gupta <rajat.gupta@oss.qualcomm.com> Link: https://patch.msgid.link/20260507043531.492-1-rajat.gupta@oss.qualcomm.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peerElXreno1-0/+3
On a STATION vif, removing a TDLS peer takes the mt7925_mac_sta_remove -> mt7925_mac_sta_remove_links path. The first loop in that function calls mt7925_mcu_add_bss_info(..., enable=false) for every link of the station being removed. For a non-MLO STATION vif there is exactly one link, link 0, whose bss_conf is the AP's. TDLS peers do not have their own bss_conf - they share the AP's BSS. The result is that every TDLS peer teardown sends a BSS_INFO_UPDATE with enable=0 for the AP's BSS to the firmware, which wipes the AP-side rate-control context. The connection stays associated and TX from the host still works at the negotiated rate, but the AP's downlink to us collapses to the lowest mandatory OFDM rate (HE-MCS 0 / 6 Mbit/s OFDM) and only slowly recovers as rate adaptation re-learns under sustained traffic. With brief or bursty traffic the link can stay at 6-72 Mbit/s indefinitely, requiring a manual reconnect. mt7925_mac_link_sta_remove() already guards its own mt7925_mcu_add_bss_info(..., false) call with "vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls". Add the equivalent guard at the top of the cleanup loop in mt7925_mac_sta_remove_links(), above the link_sta / link_conf / mlink / mconf lookups, so TDLS peer teardown skips the loop body entirely without doing the per-link work that would just be thrown away. Verified on mt7925e by triggering Samsung-S938B auto-TDLS via iperf3 and watching iw rx bitrate after teardown: Before: rx bitrate collapses to 6.0-72.0 Mbit/s, oscillates 17/72/ 137/288/432 Mbit/s for 30+ seconds, no full recovery without a manual reassoc. After: rx bitrate stays at 1200.9 Mbit/s HE-MCS 11 NSS 2 80 MHz across the entire TDLS lifecycle. bpftrace confirms a single mt7925_mcu_add_bss_info(enable=0) call per teardown before the fix; zero such calls after. Fixes: 3878b4333602 ("wifi: mt76: mt7925: update mt7925_mac_link_sta_[add, assoc, remove] for MLO") Cc: stable@vger.kernel.org Signed-off-by: ElXreno <elxreno@gmail.com> Assisted-by: Claude:claude-opus-4-7 bpftrace Link: https://patch.msgid.link/20260506-mt7925-tdls-fixes-v2-2-46aa826ba8bb@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: route TDLS-peer frames as 3-addr non-DS in HW encapElXreno8-0/+28
With HW TX encap offload enabled, the mt76 firmware builds the 802.11 header for the 802.3 frame using the per-WCID context. For a STATION vif the HDR_TRANS TLV currently sets ToDS=1, which makes the firmware default to the BSSID as A1 and emit STA->AP-formatted frames regardless of which peer the WCID points to. For TDLS-paired peers this is wrong. Data frames go on air addressed to the AP, the AP MAC-ACKs and silently drops them per IEEE 802.11z (an AP must not forward to a TDLS-paired peer). Management and control frames bypass the HW encap path and still reach the peer; only user data fails. Add MT_WCID_FLAG_TDLS_PEER, set it in mt7915, mt7921, mt7925 and mt7996 sta-add paths when sta->tdls is true, and override the HDR_TRANS TLV in mt76_connac_mcu_wtbl_hdr_trans_tlv() (Connac2 - mt7915 / mt7921 / mt7922), mt7925_mcu_sta_hdr_trans_tlv() (mt7925) and mt7996_mcu_sta_hdr_trans_tlv() (mt7996) to set ToDS=0, FromDS=0 when the flag is set. The 3-addr non-DS form matches what 802.11z uses for direct links; the firmware then constructs the frame with A1=peer rather than A1=BSSID. HW encap offload remains enabled for AP and any non-TDLS traffic. Verified on mt7925e + Samsung S938B over a 5 GHz HE 80 MHz channel with iperf3 -t 30 to the TDLS peer: before fix: over the TDLS direct link, 7 TDLS Setup action frames and 3 RTS frames reach the peer; 0 QoS Data frames make it through (mgmt/control paths bypass HW encap, the data path does not). iperf3 stalls. after fix: 2.90 GBytes transferred at 830 Mbit/s sustained, 0 TCP retransmits. mt7915, mt7921, mt7922 and mt7996 are not regression-tested in this change for lack of hardware. Their HDR_TRANS handling mirrors the verified mt7925 change; the firmware behavior is shared across these chips. Signed-off-by: ElXreno <elxreno@gmail.com> Assisted-by: Claude:claude-opus-4-7 bpftrace tcpdump Link: https://patch.msgid.link/20260506-mt7925-tdls-fixes-v2-1-46aa826ba8bb@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beaconArjan van de Ven2-0/+6
This patch is based on a BUG as reported by Bongani Hlope at https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/ When a channel-switch announcement (CSA) beacon is received, cfg80211 queues a wiphy work item that eventually calls mt7921_channel_switch_rx_beacon(). If the station disconnects (or the channel context is otherwise torn down) between the time the work is queued and the time it runs, the driver's dev->new_ctx pointer can already have been cleared to NULL. mt7921_channel_switch_rx_beacon() then dereferences new_ctx unconditionally, triggering a NULL pointer dereference at address 0x0: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:mt7921_channel_switch_rx_beacon+0x1f/0x100 [mt7921_common] The same missing guard exists in mt7925_channel_switch_rx_beacon(), which shares the same code pattern introduced by the same commit. Add an early-return NULL check for dev->new_ctx in both mt7921_channel_switch_rx_beacon() and mt7925_channel_switch_rx_beacon(). When new_ctx is NULL there is no pending channel switch to process, so returning immediately is the correct and safe action. Fixes: 8aa2f59260eb ("wifi: mt76: mt7921: introduce CSA support") Reported-by: Bongani Hlope <developer@hlope.org.za> Oops-Analysis: http://oops.fenrus.org/reports/lkml/20260502125824.425d7159@bongani-mini.home.org.za/report.html Link: https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/ Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Cc: linux-wireless@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: Felix Fietkau <nbd@nbd.name> Cc: Lorenzo Bianconi <lorenzo@kernel.org> Cc: Ryder Lee <ryder.lee@mediatek.com> Link: https://patch.msgid.link/20260504145107.1329197-1-arjan@linux.intel.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: fix resource leak in probe error pathHongling Zeng1-5/+10
When pcim_iomap_region() or devm_kmemdup() fail, the code returns directly without cleaning up previously allocated resources: - mt76_device allocated by mt76_alloc_device() - pci irq vectors allocated by pci_alloc_irq_vectors() Fix this by jumping to the existing error cleanup path instead of returning directly. Fixes: ee5bb35d2b83 ("wifi: mt76: mt7921: Replace deprecated PCI function") Fixes: 222606f43b58 ("wifi: mt76: mt7921: handle MT7902 irq_map quirk with mutable copy") Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Link: https://patch.msgid.link/20260512065245.46496-1-zenghongling@kylinos.cn Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: fix of_get_mac_address error handlingRosen Penev1-1/+1
Check return value instead of is_valid_ether_addr. The latter is handled by the former. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260427051746.954704-1-rosenp@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: clean up DMA on probe failureMyeonghun Pak1-1/+3
mt7925_pci_probe() initializes DMA before registering the device. If mt7925_register_device() fails, probe returns through err_free_irq without tearing down DMA state. That leaves the TX NAPI instance enabled and skips the DMA queue cleanup that the normal remove path performs through mt7925e_unregister_device(). Add a dedicated unwind label for failures after mt7925_dma_init() succeeds. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Link: https://patch.msgid.link/20260426143728.41534-1-pakmyeonghun@bagmyeonghun-ui-MacBookPro.local Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09r8152: handle the return value of usb_reset_device()Chih Kai Hsu1-1/+6
If usb_reset_device() returns a negative error code, stop the process of probing. Fixes: 10c3271712f5 ("r8152: disable the ECM mode") Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com> Reviewed-by: Hayes Wang <hayeswang@realtek.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260604092247.27158-450-nic_swsd@realtek.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-08net/mlx5: Use effective affinity mask for IRQ selectionFushuai Wang1-1/+4
When a sf is created after a CPU has been taken offline, the IRQ pool may contain IRQs with affinity masks that include the offline CPU. Since only online CPUs should be considered for IRQ placement, cpumask_subset() check would fail because the iter_mask contains offline CPUs that are not present in req_mask, causing sf creation to fail. This is an example: 1. When mlx5 driver loads, it initializes the IRQ pools. For sf_ctrl_pool with ≤64 sf: - xa_num_irqs = {N, N} (There is only one slot) 2. When the first SF is created: - The ctrl IRQ is allocated with mask=cpu_online_mask={0-191} 2. We take CPU 20 offline 3. Existing ctl irq still have mask={0-191} 4. Create a new SF: - req_mask={0-19,21-191} - iter_mask={0-191} - {0-191} is NOT a subset of {0-19,21-191} - least_loaded_irq=NULL 5. Try to allocate a new irq via irq_pool_request_irq() 6. xa_alloc() fails because the pool is full(There is only one slot) 7. sf creation fails with error Use irq_get_effective_affinity_mask() instead, which returns the IRQ's actual effective affinity that already excludes offline CPUs. Fixes: 061f5b23588a ("net/mlx5: SF, Use all available cpu for setting cpu affinity") Suggested-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260605102112.91772-1-fushuai.wang@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net/mlx5: Simplify cpumask operations in comp_irq_request_sf()Fushuai Wang1-2/+1
Combine cpumask_copy() and cpumask_andnot() into a single cpumask_andnot() since the function can take cpu_online_mask directly as the source. Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260605101756.91275-1-fushuai.wang@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failureDragos Tatulea1-2/+8
In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed. Fixes: 84a0a2310d6d ("net/mlx5e: XDP_TX from UMEM support") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260604135446.456119-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_listDragos Tatulea2-28/+57
mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 </TASK> Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max. Fixes: e16aea2744ab ("net/mlx5: Introduce access functions to modify/query vport mac lists") Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260604135849.458060-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: phy: don't try to setup PHY-driven SFP cages when using genphyMaxime Chevallier1-3/+9
We don't have support for PHY-driver SFP cages with the genphy code. On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers. This problem was reproduced, and does lead to a deadlock on RTNL. Before the blamed commit, the phy_sfp_probe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy. Let's therefore only run phy_sfp_probe when not using genphy. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Fixes: bad869b5e41a ("net: phy: Only rely on phy_port for PHY-driven SFP") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260604092819.723505-5-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: phy: Clean the phy_ports after unregistering the downstream SFP busMaxime Chevallier1-2/+2
As reported by sashiko when looking a other patches, we need to ensure that the downstream SFP bus gets unregistered prior to destroying the phy_ports attached to a phy_device, as the SFP code may reference these ports. Let's make sure we follow that ordering in phy_remove(). Fixes: 589e934d2735 ("net: phy: Introduce PHY ports representation") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Link: https://patch.msgid.link/20260604092819.723505-4-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: phy: remove phy ports upon probe failureMaxime Chevallier1-0/+2
When phy_probe fails, let's clean the phy_ports that were successfully added already. Suggested-by: Nicolai Buchwitz <nb@tipi-net.de> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Fixes: 589e934d2735 ("net: phy: Introduce PHY ports representation") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260604092819.723505-3-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: phy: clean the sfp upstream if phy probing failsMaxime Chevallier1-0/+6
Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Fixes: 298e54fa810e ("net: phy: add core phylib sfp support") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260604092819.723505-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: ibm: emac: mal: fix potential system hang in mal_remove()Rosen Penev1-3/+3
napi_disable() is not idempotent and calling it on an already-disabled or unenabled NAPI context will cause the kernel to spin indefinitely waiting for the NAPI_STATE_SCHED bit to clear. In mal_remove(), napi_disable() is called unconditionally. If no MACs were registered, NAPI was never enabled. Also, if they were registered but subsequently unregistered, NAPI was already disabled in mal_unregister_commac(). In either case, calling napi_disable() causes the kernel to hang upon module removal. Fix this by only calling napi_disable() in mal_remove() if the commac list is not empty (which implies NAPI is enabled). Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260603230821.5619-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: ibm: emac: Clear MAL descriptors without memsetRosen Penev1-2/+13
Clear MAL descriptor rings with explicit field stores instead of memset(). The descriptor rings are carved from MAL coherent DMA memory, which may be mapped uncached on 32-bit powerpc. The optimized memset() path can use dcbz there and trigger an alignment warning. Use WRITE_ONCE() for each field to prevent the compiler from merging the stores back into a memset() call. The skb tracking arrays remain ordinary CPU memory and still use memset(). Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260603230754.5535-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: ibm: emac: Fix use-after-free during device removalRosen Penev1-1/+8
The driver was using devm_register_netdev() which causes unregister_netdev() to be deferred until the devres cleanup phase, which runs after emac_remove() returns. This creates a use-after-free window where: 1. emac_remove() is called, which tears down hardware (cancels work, detaches modules, unregisters from MAL) 2. emac_remove() returns 3. devres cleanup runs and finally calls unregister_netdev() During step 3, the network stack might still process packets, triggering emac_irq(), emac_poll(), or other handlers that access now-freed hardware resources (dev->emacp, dev->mal, etc.). Fix this by replacing devm_register_netdev() with manual register_netdev() and calling unregister_netdev() at the beginning of emac_remove(), before any hardware teardown. This ensures the network device is fully stopped and unregistered before hardware resources are released. The change is safe because: - dev->ndev is assigned very early in probe (before any error paths that could bypass emac_remove) - platform_set_drvdata() is only called after successful registration, so emac_remove() only runs for fully registered devices - unregister_netdev() is idempotent and safe to call on any registered device Fixes: a4dd8535a527 ("net: ibm: emac: use devm for register_netdev") Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net: ibm: emac: mal: fix unchecked platform_get_irq return valuesRosen Penev1-0/+9
platform_get_irq() returns a negative errno on failure. Commit c4f5d0454cab5 moved the platform_get_irq() calls and explicitly removed the error checks that were previously present, claiming devm_request_irq() can handle it. However, a negative IRQ number passed to devm_request_irq() fails with -EINVAL instead of propagating the real error from platform_get_irq(). Restore the missing error checks with proper errno propagation. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260603211734.30750-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08net/mlx4: avoid GCC 10 __bad_copy_from() false positiveYao Sang1-1/+8
mlx4_init_user_cqes() fills a scratch buffer with the CQE initialization pattern and then copies from that buffer to userspace. In the single-copy path, the copy length is array_size(entries, cqe_size), but the scratch buffer is allocated with PAGE_SIZE. GCC 10 does not carry the branch invariant strongly enough through the object size checks and falsely triggers __bad_copy_from(). Size the scratch buffer to the actual copy length for the active path, keep array_size() for the single-copy case, and retain a WARN_ON_ONCE() guard for the PAGE_SIZE invariant before allocating the buffer. Fixes: f69bf5dee7ef ("net/mlx4: Use array_size() helper in copy_to_user()") Signed-off-by: Yao Sang <sangyao@kylinos.cn> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08pds_core: quiesce DMA before freeing resourcesNikhil P. Rao1-0/+4
pdsc_teardown() frees DMA buffers but does not disable bus mastering, leaving the device able to perform DMA after the buffers are freed. This can lead to use-after-free if the device writes to freed memory. Add pci_clear_master() to pdsc_teardown() to disable bus mastering before freeing resources, ensuring all DMA is quiesced. Add pci_set_master() to pdsc_setup() to re-enable bus mastering, which is needed for the firmware recovery path since pdsc_teardown() now disables it. Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Link: https://patch.msgid.link/20260604213637.3844317-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-08geneve: Move udp_conf.local_ip6 under CONFIG_IPV6 in geneve_create_sock().Kuniyuki Iwashima1-1/+4
Unlike struct ip_tunnel_key, struct udp_port_cfg does not always define IPv6 address fields. >> drivers/net/geneve.c:778:12: error: no member named 'local_ip6' in 'struct udp_port_cfg' 778 | udp_conf.local_ip6 = info->key.u.ipv6.src; | ~~~~~~~~ ^ Let's add CONFIG_IPV6 guard in geneve_create_sock(). Fixes: afabbb56a726 ("geneve: Introduce IFLA_GENEVE_LOCAL and IFLA_GENEVE_LOCAL6.") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202606070019.yx2LhZPU-lkp@intel.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Link: https://patch.msgid.link/20260606204848.1987046-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-06wifi: ath9k_htc: allocate tx_buf and buf togetherRosen Penev2-13/+3
Use a flexible array member to combine allocations. No need to have them separate as they are always together. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Link: https://patch.msgid.link/20260521232020.261405-1-rosenp@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-27 11:47:56 +0000