kernel/git/stable/linux-stable.git/drivers/net/wireless, branch linux-6.18.y

wifi: mt76: fix airoha_npu dependency tracking

2026-09-14T11:36:19+00:00

commit 7cd57ff6c6263519e6e463cbc2e0898828a70c42 upstream. There is a new build failure with MT7996E=m MT76_CORE=y and NET_AIROHA_NPU=m: ld.lld: error: undefined symbol: airoha_npu_get ld.lld: error: undefined symbol: airoha_npu_put >>> referenced by npu.c >>> drivers/net/wireless/mediatek/mt76/npu.o:(mt76_npu_init) in archive vmlinux.a Fix this by reworking the dependency for the MT7996_NPU to only allow enabling that when mt76_core can link against the npu driver. To make sure this gets caught more easily in the future when additional mt76 variants need the same dependency, also turn CONFIG_MT76_NPU into a tristate symbol that has the same dependency. Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer") Acked-by: Lorenzo Bianconi Signed-off-by: Arnd Bergmann Link: https://patch.msgid.link/20260612201519.4054683-1-arnd@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman

wifi: mt76: npu: Add missing rx_token_size initialization

2026-09-14T11:36:17+00:00

[ Upstream commit 25e3203a2192f2b0d697b2410126bad87e62d4f0 ] Add missing rx_token_size initialization for NPU offloading. Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer") Tested-by: Kang Yang Signed-off-by: Lorenzo Bianconi Link: https://patch.msgid.link/20260122-mt76-npu-eagle-offload-v2-2-2374614c0de6@kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: restrict NPU/PPE active checks to MMIO devices

2026-09-14T11:36:17+00:00

[ Upstream commit 7981aca2bd28a1f7ad7eeab89715442a95b1f72e ] mt76_npu_device_active() and mt76_ppe_device_active() read dev->mmio.npu and dev->mmio.ppe_dev. The mmio, usb and sdio bus structs share a union in struct mt76_dev, so on USB and SDIO these read unrelated data from the usb/sdio struct, which is non-NULL in practice. mt76_npu_device_active() then returns true on USB, and mt76_rx_poll_complete() takes the offload path and skips mt76_rx_aggr_reorder(). RX A-MPDU subframes are delivered out of order and the peer's TCP stack treats that as loss: heavy retransmissions and reduced throughput in AP mode. Seen on mt7921u, mt7925u, mt76x2u and mt76x0u. Gate both helpers on mt76_is_mmio() so they only run for the bus type that owns the mmio union member. Fixes: 7fb554b1b623 ("wifi: mt76: Introduce the NPU generic layer") Cc: stable@vger.kernel.org Tested-by: Nick Morrow Signed-off-by: Devin Wittmayer Link: https://patch.msgid.link/20260720232640.41293-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: zd1211rw: reject secondary interfaces to prevent conflicts

2026-09-14T11:35:28+00:00

[ Upstream commit 0e4532ec658606f76f62eb277e7a933919d36cbb ] The zd1211rw driver is designed for single-function Wi-Fi dongles and hardcodes its USB endpoints. When a malformed USB device exposes multiple interfaces that match the driver's device ID, the driver blindly binds to all of them. During probe(), the driver calls usb_reset_device(), which iterates over all interfaces and invokes the pre_reset() callback for each bound interface. Since multiple interfaces are bound to zd1211rw, pre_reset() is called sequentially for each instance, acquiring their respective &mac->chip.mutex. Because all instances initialize their mutexes with the same lock class, lockdep detects a task acquiring a lock of the same class it already holds and flags it as a possible recursive deadlock: WARNING: possible recursive locking detected kworker/0:1/11 is trying to acquire lock: ffff88810371dde0 (&chip->mutex){+.+.}-{4:4}, at: zd_chip_disable_rxtx+0x20/0x50 drivers/net/wireless/zydas/zd1211rw/zd_chip.c:1465 but task is already holding lock: ffff8881138ddde0 (&chip->mutex){+.+.}-{4:4}, at: pre_reset+0x28c/0x380 drivers/net/wireless/zydas/zd1211rw/zd_usb.c:1505 Fix this by explicitly rejecting secondary interfaces (bInterfaceNumber != 0) during probe(). This ensures that only a single instance of the driver binds to the device, eliminating the recursive locking scenario. Fixes: e85d0918b54f ("[PATCH] ZyDAS ZD1211 USB-WLAN driver") Assisted-by: Gemini:gemini-3.5-flash Gemini:gemini-3.1-pro-preview syzbot Reported-by: syzbot+0ec3d1a6cf1fbe79c153@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0ec3d1a6cf1fbe79c153 Link: https://syzkaller.appspot.com/ai_job?id=00724ef7-fd77-4cde-9779-895b8f63c2f6 Signed-off-by: Slawomir Stepien Link: https://patch.msgid.link/20260730065231.1644030-1-sst@poczta.fm Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mt76: mt7996: remove beacon_int_min_gcd from ADHOC interface combinations

2026-09-14T11:35:27+00:00

[ Upstream commit 4df22710a77d2365e56d720bc4106e54c1dfa2ff ] The driver fails to register with error -22 (EINVAL) due to a cfg80211 validation failure in wiphy_verify_iface_combinations(). Commit 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") added beacon_int_min_gcd to if_comb_global and if_comb_global_7992, but these combinations include ADHOC (IBSS) interface type. This violates a cfg80211 rule from commit 56271da29c52 ("cfg80211: disallow beacon_int_min_gcd with IBSS") that explicitly forbids combining ADHOC with beacon_int_min_gcd. The restriction exists because beacon_int_min_gcd requires static, predictable beacon intervals to coordinate multiple beaconing interfaces, but ADHOC interfaces have dynamic beacon intervals that change when joining different networks, making the GCD constraint unenforceable. Remove beacon_int_min_gcd from the interface combinations that include ADHOC because they are not necessary for ADHOC operation. The if_comb combination (AP/MESH/STA only, without ADHOC) correctly retains beacon_int_min_gcd for multi-AP coordination. Fixes: 5ef0e8e2653b ("wifi: mt76: mt7996: fix iface combination for different chipsets") Signed-off-by: Jose Ignacio Tornos Martinez Tested-by: Alex Gavin Link: https://patch.msgid.link/20260702104337.679536-1-jtornosm@redhat.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump

2026-09-14T11:35:27+00:00

[ Upstream commit 4f25071afe9218aaae1c63fbf75e229aa6405319 ] On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1 Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990") Signed-off-by: Linghui Wu Reviewed-by: Rameshkumar Sundaram Reviewed-by: Baochen Qiang Link: https://patch.msgid.link/20260727072629.2297208-1-linghui.wu@oss.qualcomm.com Signed-off-by: Jeff Johnson Signed-off-by: Sasha Levin

wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx()

2026-09-14T11:35:27+00:00

[ Upstream commit 4330a0ef9f75a54fde3548432a9a698f06bab635 ] When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well. Fixes: 1609b014aa29 ("wifi: mt76: mt7996: Overwrite unspecified link_id in mt7996_tx()") Link: https://patch.msgid.link/20260801145334.1166751-10-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: reject out-of-range link ids in mt76_vif_link()

2026-09-14T11:35:27+00:00

[ Upstream commit 9ba744a28c26eaa5cae930688a22e01888395308 ] mt76_vif_link() indexes mvif->link[] without validating link_id, but callers pass mvif->deflink_id / msta->deflink_id, which hold IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added. Since IEEE80211_MLD_MAX_NUM_LINKS is 15, that reads one element past the end of the array, aliasing mt76_vif_data.offchannel_link. Reachable via mt7996_set_tsf()/mt7996_offset_tsf() and mt7996_net_fill_forward_path(). Bounds check link_id and return NULL, matching mt7996_sta_link() and mt7996_sta_link_protected(). Fixes: a9384b36a42a ("wifi: mt76: mt7996: rework set/get_tsf callabcks to support MLO") Link: https://patch.msgid.link/20260801145334.1166751-9-nbd@nbd.name Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be minimum

2026-09-14T11:35:27+00:00

[ Upstream commit 404c4e564f6b1eeffd10bf2b2d3b86620f5794c3 ] Per IEEE 802.11be, the Beamformee SS <= 80/160/320 MHz 3-bit subfields in the EHT PHY Capabilities are encoded as (Nss - 1) and are required to be >= 3 (i.e. at least 4 SS receive capability) whenever SU Beamformee is advertised. MT7925 is a 2x2 STA (sts = 2), so directly filling (sts - 1) = 1 violates the spec minimum. Clamp the encoded value to 3 when sts <= 3, otherwise use (sts - 1). This is applied consistently to the BEAMFORMEE_SS <= 80 MHz (split across phy_cap_info[0]/[1]), <= 160 MHz and <= 320 MHz (6 GHz only) subfields. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: shengwei.lu Link: https://patch.msgid.link/20260723031108.2017653-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin

wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band

2026-09-14T11:35:27+00:00

[ Upstream commit 77833c57a33450c0409e4b90d7721d255ea23a9e ] 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 Tested-by: Cristian-Florin Radoi Tested-by: George Salukvadze Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo Tested-by: Ariel Rosenfeld Tested-by: Chapuis Dario Tested-by: Thibaut François Tested-by: 张旭涵 Reviewed-by: Sean Wang Signed-off-by: Javier Tia Link: https://patch.msgid.link/20260425195011.790265-6-sean.wang@kernel.org Signed-off-by: Felix Fietkau Stable-dep-of: 404c4e564f6b ("wifi: mt76: mt7925: Fix EHT Beamformee SS subfields to meet 802.11be minimum") Signed-off-by: Sasha Levin