Wen Gong [Thu, 4 Jun 2026 09:58:31 +0000 (15:28 +0530)]
wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported
When firmware reports NSS ratio support, SUPPORTS_VHT_EXT_NSS_BW is enabled in
ath12k. However, IEEE80211_VHT_EXT_NSS_BW_CAPABLE must also be set to make the
advertisement valid.
According to IEEE Std 802.11-2024, Subclause 9.4.2.156.3 (Supported VHT-MCS and
NSS Set subfields), the VHT Extended NSS BW Capable bit indicates whether a STA
is capable of interpreting the Extended NSS BW Support subfield of the VHT
capabilities information field. Advertising extended NSS BW support without
setting this capability bit is therefore invalid.
Without this change, mac80211 detects the inconsistency and logs:
ieee80211 phy0: copying sband (band 1) due to VHT EXT NSS BW flag
This indicates that mac80211 implicitly aligns IEEE80211_VHT_EXT_NSS_BW_CAPABLE
during ieee80211_register_hw(). Explicitly setting the bit in ath12k avoids this
fixup and ensures capabilities are advertised correctly by the driver.
This change follows the same approach as the existing ath11k fix.
https://lore.kernel.org/all/20211013073704.15888-1-wgong@codeaurora.org/
Baochen Qiang [Tue, 9 Jun 2026 02:10:47 +0000 (10:10 +0800)]
wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits
On WCN7850, after the following sequence:
1. load ath12k and connect to a non-MLO AP
2. disconnect and connect to an MLO AP
3. disconnect and reconnect to the non-MLO AP
the third connection always fails with a 4-Way handshake timeout. The
supplicant transmits message 2 of 4 four times in response to AP
retries of message 1, but the AP never sees any of them.
ath12k_dp_vdev_tx_attach() composes dp_link_vif->tcl_metadata using |=,
but dp_link_vif is embedded in struct ath12k_dp_vif and its slots are
reused across vif/peer teardown and setup. Since tcl_metadata is never
cleared on detach, vdev_id bits from a previous attach remain set when
the same link slot is reused with a different vdev_id. In this specific
issue, the same link slot is used for vdev_id 0, then vdev_id 1, then
vdev_id 0 again, the OR yields tcl_metadata == 0x9, which encodes
vdev_id 1 in the HTT_TCL_META_DATA_VDEV_ID field even though
ti.vdev_id is 0. Firmware then routes the EAPOL frame to the wrong
vdev and the AP never receives message 2.
Use plain assignment instead of |= so the field is fully recomputed
from the current arvif on every attach.
Ingyu Jang [Tue, 19 May 2026 08:52:14 +0000 (17:52 +0900)]
wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks
mt76_register_debugfs_fops() returns the dentry from
debugfs_create_dir(), which yields an error pointer on failure
(notably ERR_PTR(-ENODEV) when CONFIG_DEBUG_FS=n), never NULL. Per
commit ff9fb72bc077 ("debugfs: return error values, not NULL"),
callers do not need to check the return value.
Drop the dead !dir checks in mt7615/mt7915/mt7921/mt7925/mt7996
_init_debugfs(). Converting them to IS_ERR() instead would have
exposed a probe abort on CONFIG_DEBUG_FS=n, since each
*_init_debugfs() caller propagates the helper's return value.
This patch supersedes an earlier proposal that converted the checks
to IS_ERR().
Devin Wittmayer [Fri, 15 May 2026 18:39:21 +0000 (11:39 -0700)]
wifi: mt76: mt7921: assert sniffer on chanctx change
mt7921_change_chanctx() configures the channel for monitor vifs but
does not re-assert sniffer mode. mt7925_change_chanctx() does. Match
mt7925 by adding the missing mt7921_mcu_set_sniffer(true) call,
completing the architectural pattern from commit 914189af23b8 ("wifi:
mt76: mt7921: fix channel switch fail in monitor mode").
The user-visible regression this asymmetry produced on v6.17 and v6.18
was addressed by commit cdb2941a516c ("Revert "wifi: mt76: mt792x:
improve monitor interface handling"") in v6.19 and backported to the
6.17.y and 6.18.y stable trees. This patch is defense in depth in
case the NO_VIRTUAL_MONITOR change is reintroduced in a future series.
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
JB Tsai [Tue, 3 Mar 2026 05:36:36 +0000 (13:36 +0800)]
wifi: mt76: mt7921: add auto regdomain switch support
Implement 802.11d-based automatic regulatory domain switching to
dynamically determine the regulatory domain at runtime.
The scan-done event structure by reusing reserved padding and appending
new fields; the layout and values remains backward-compatible with
existing users.
Sean Wang [Wed, 1 Apr 2026 18:23:22 +0000 (13:23 -0500)]
wifi: mt76: mt792x: report txpower for the requested vif link
mt792x currently reports txpower from the generic PHY cached state,
which may not match the requested vif/link context.
Resolve the requested link channel and derive txpower from that channel
instead, with fallback to the current PHY chandef if no valid chanctx is
available.
Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca> Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/ Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Tested-by: Satadru Pramanik <satadru@gmail.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260401182322.64355-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
wifi: mt76: mt7996: limit work in set_bitrate_mask
Calls to mt7996_set_bitrate_mask() would propagate work for all stations
on the ieee80211_hw regardless of the vif specified in the call. To
prevent unnecessary work in FW, limit setting the sta_rate to only the
specified vif in mt7996_sta_rate_ctrl_update().
Fixes: afff4325548f0 ("wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback") Signed-off-by: Dylan Eskew <dylan.eskew@candelatech.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260408145057.2356878-2-dylan.eskew@candelatech.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
wifi: mt76: mt7996: reduce phy work in set_coverage
In mt7996_set_coverage_class(), each phy is iterated over in calling
mt7996_mac_set_coverage_class(). Thus, the phy2 and phy3 configuration
logic in mt7996_mac_set_coverage_class() can be dropped.
Sean Wang [Sat, 25 Apr 2026 16:09:30 +0000 (11:09 -0500)]
wifi: mt76: mt7921u: add MT7902 USB support
Add the 0e8d:7902 USB ID and select the MT7902 WM firmware. Use the
same USB queue mapping as mt7921/mt7925 so MT7902U can bind and probe
through mt7921u driver.
Jiajia Liu [Tue, 2 Jun 2026 05:43:49 +0000 (13:43 +0800)]
wifi: mt76: transform aspm_conf for pci_disable_link_state
commit b478e162f227 ("PCI/ASPM: Consolidate link state defines") changed
PCIE_LINK_STATE_L0S (1) to (BIT(0) | BIT(1)). PCI_EXP_LNKCTL_ASPM_L0S (1)
and PCI_EXP_LNKCTL_ASPM_L1 (2) are no longer matched with
PCIE_LINK_STATE_L0S (3) and PCIE_LINK_STATE_L1 (4).
On the platform enabling ASPM L0s and L1, mt76_pci_disable_aspm is not able
to disable L1. Fix this by transforming aspm_conf to pcie link state.
Jiajia Liu [Thu, 28 May 2026 03:38:14 +0000 (11:38 +0800)]
wifi: mt76: add wcid publish check in mt76_sta_add
Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
to avoid reinitializing the wcid->poll_list.
Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
According to the corruption information, prev->next was changed to itself.
wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
Lorenzo Bianconi [Fri, 22 May 2026 07:24:52 +0000 (09:24 +0200)]
wifi: mt76: mt7996: remove redundant pdev->bus check in probe
Drop the unnecessary pdev->bus NULL check in mt7996_pci_probe() since
the pointer is already dereferenced earlier in mt76_pci_disable_aspm(),
making the check dead code. Silences the related Smatch warning.
Lorenzo Bianconi [Sun, 31 May 2026 08:55:04 +0000 (10:55 +0200)]
wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add()
mt76_tx_status_skb_add() zeroes the mt76_tx_cb struct stored at
info->status.status_driver_data via memset(). Since info->control and
info->status are members of the same union in ieee80211_tx_info,
this overwrites info->control.flags.
In mt7996_tx_prepare_skb(), mt76_tx_status_skb_add() is called before
mt7996_mac_write_txwi(), which re-reads info->control.flags to extract
IEEE80211_TX_CTRL_MLO_LINK. Because the field has been zeroed, the
link_id always resolves to 0 for frames using global_wcid, leading to
incorrect TXWI configuration.
Fix this by passing link_id as an explicit parameter to
mt7996_mac_write_txwi(). In mt7996_tx_prepare_skb(), the link_id is
already extracted from info->control.flags before the destructive
mt76_tx_status_skb_add() call. For the beacon and inband discovery
callers in mcu.c, use link_conf->link_id directly.
Lorenzo Bianconi [Sun, 31 May 2026 09:38:57 +0000 (11:38 +0200)]
wifi: mt76: mt7996: Fix possible NULL pointer dereference in mt7996_mac_write_txwi_80211()
For injected frames (e.g. via radiotap), mac80211 can pass
info->control.vif = NULL, as explicitly noted in struct ieee80211_tx_info.
Check vif pointer before executing ieee80211_vif_is_mld() in
mt7996_mac_write_txwi_80211 routine in order to avoid a possible NULL
pointer dereference.
Lorenzo Bianconi [Sun, 31 May 2026 09:10:59 +0000 (11:10 +0200)]
wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()
If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine,
mt7996 driver leaks an already allocated tx token. Fix the issue
releasing the token in case of error.
wifi: mt76: mt7915: validate skb length in txpower SKU query
In mt7915_mcu_get_txpower_sku(), the response skb from
mt76_mcu_send_and_get_msg() is used in memcpy without validating
its length:
For TX_POWER_INFO_RATE:
memcpy(res, skb->data + 4, sizeof(res));
where sizeof(res) is MT7915_SKU_RATE_NUM * 2 = 322 bytes.
For TX_POWER_INFO_PATH:
memcpy(txpower, skb->data + 4, len);
In both cases, if the firmware returns a response shorter than
the expected size, the memcpy reads beyond the skb data buffer.
The data surfaces to userspace via debugfs (txpower_sku and
txpower_path).
Add length checks for both code paths before the memcpy.
where MT7925_EVT_RSP_LEN is 512. If the firmware returns a response
shorter than 520 bytes (8 + 512), this reads beyond the skb data
buffer. The over-read data is then returned to userspace via nla_put()
in mt7925_testmode_dump().
Add a length check before the memcpy to ensure the skb contains
sufficient data.
mt792x_tx() rewrites addr1/addr2/addr3 by treating skb->data as
an 802.11 header for MLD traffic.
That is only valid for native 802.11 frames. Direct 802.3 TX can also
reach this path with IEEE80211_TX_CTL_HW_80211_ENCAP set, where
skb->data is not an 802.11 header.
Skip the MLD header rewrite for HW-encap packets to avoid corrupting
802.3 frame contents.
Sean Wang [Sat, 25 Apr 2026 15:47:21 +0000 (10:47 -0500)]
wifi: mt76: mt7925: program BA state on active links
With MLO, traffic for one TID can be sent on any active link. Programming
BA state only on the default link leaves the other active links out of
sync.
Program BA state on all active links instead.
Fixes: 766ea2cf5a39 ("Revert "wifi: mt76: mt7925: Update mt7925_mcu_uni_[tx,rx]_ba for MLO"") Tested-by: Yao Ting Hsieh <yao-ting.hsieh@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425154721.738101-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Sat, 25 Apr 2026 15:47:19 +0000 (10:47 -0500)]
wifi: mt76: mt7925: keep TX BA state in the primary WCID
For MLO, the same TID can run over different links. Keeping TX BA state in
a link WCID makes the state depend on which link starts aggregation first.
Store it in the primary WCID instead, so the BA state stays stable across
links.
Fixes: 44eb173bdd4f ("wifi: mt76: mt7925: add link handling in mt7925_txwi_free") Tested-by: Yao Ting Hsieh <yao-ting.hsieh@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425154721.738101-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Sat, 25 Apr 2026 19:50:09 +0000 (14:50 -0500)]
wifi: mt76: mt792x: enable CNM ops for MT7927
Enable CNM support for MT7927 so mac80211 keeps remain-on-channel callbacks
available. MT7927 needs them at runtime even when the capability is not
advertised through the normal firmware feature path.
Sean Wang [Sat, 25 Apr 2026 19:50:07 +0000 (14:50 -0500)]
wifi: mt76: mt7925: sync MT7927 BSS band assignment
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.
Sean Wang [Sat, 25 Apr 2026 19:50:03 +0000 (14:50 -0500)]
wifi: mt76: mt792x: add MT7927 WFSYS reset support
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.
Javier Tia [Sat, 25 Apr 2026 19:49:59 +0000 (14:49 -0500)]
wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
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.
Javier Tia [Sat, 25 Apr 2026 19:49:58 +0000 (14:49 -0500)]
wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
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>
Javier Tia [Sat, 25 Apr 2026 19:49:57 +0000 (14:49 -0500)]
wifi: mt76: mt7925: add MT7927 firmware paths
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>
Javier Tia [Sat, 25 Apr 2026 19:49:56 +0000 (14:49 -0500)]
wifi: mt76: mt7925: add MT7927 chip ID helpers
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>
Javier Tia [Sat, 25 Apr 2026 19:49:55 +0000 (14:49 -0500)]
wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
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>
Javier Tia [Sat, 25 Apr 2026 19:49:54 +0000 (14:49 -0500)]
wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
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>
Javier Tia [Sat, 25 Apr 2026 19:49:53 +0000 (14:49 -0500)]
wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
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>
Javier Tia [Sat, 25 Apr 2026 19:49:52 +0000 (14:49 -0500)]
wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
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>
Javier Tia [Sat, 25 Apr 2026 19:49:51 +0000 (14:49 -0500)]
wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
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>
Lorenzo Bianconi [Sat, 18 Apr 2026 18:04:16 +0000 (20:04 +0200)]
wifi: mt76: mt7996: Fix NULL pointer dereference in mt7996_init_tx_queues()
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().
Felix Fietkau [Tue, 24 Mar 2026 15:49:03 +0000 (15:49 +0000)]
wifi: mt76: mt7996: fix out-of-bounds array access during hardware restart
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.
Johan Hovold [Thu, 30 Apr 2026 08:33:35 +0000 (10:33 +0200)]
wifi: mt7601u: drop redundant device reference
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.
Johan Hovold [Thu, 30 Apr 2026 08:33:34 +0000 (10:33 +0200)]
wifi: mt76: mt792xu: drop redundant device reference
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.
Johan Hovold [Thu, 30 Apr 2026 08:33:33 +0000 (10:33 +0200)]
wifi: mt76x2u: drop redundant device reference
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.
Johan Hovold [Thu, 30 Apr 2026 08:33:32 +0000 (10:33 +0200)]
wifi: mt76x0u: drop redundant device reference
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.
Johan Hovold [Thu, 30 Apr 2026 08:33:31 +0000 (10:33 +0200)]
wifi: mt76: drop redundant device reference
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.
Rajat Gupta [Thu, 7 May 2026 04:35:31 +0000 (21:35 -0700)]
wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link
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).
ElXreno [Wed, 6 May 2026 01:39:16 +0000 (04:39 +0300)]
wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer
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.
ElXreno [Wed, 6 May 2026 01:39:15 +0000 (04:39 +0300)]
wifi: mt76: route TDLS-peer frames as 3-addr non-DS in HW encap
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.
wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon
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:
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.
Hongling Zeng [Tue, 12 May 2026 06:52:45 +0000 (14:52 +0800)]
wifi: mt76: mt7921: fix resource leak in probe error path
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.
Myeonghun Pak [Sun, 26 Apr 2026 14:33:36 +0000 (23:33 +0900)]
wifi: mt76: mt7925: clean up DMA on probe failure
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>
Bryam Vargas [Sat, 6 Jun 2026 07:43:45 +0000 (07:43 +0000)]
wifi: mac80211: bound S1G TIM PVB walk to the TIM element
ieee80211_s1g_check_tim() parses the S1G Partial Virtual Bitmap (PVB) of a
received TIM element. The TIM is handed in as the element payload:
ieee802_11_parse_elems_full() stores elems->tim = elem->data and
elems->tim_len = elem->datalen (net/mac80211/parse.c), so the valid bytes
are [tim, tim + tim_len).
When walking the encoded blocks the function passes the walker an end
sentinel of (const u8 *)tim + tim_len + 2, i.e. two bytes past the end of
the element. ieee80211_s1g_find_target_block() loops while (ptr + 1 <= end)
and dereferences ptr (and the per-mode ieee80211_s1g_len_*() helpers read
*ptr), so it can read up to two bytes beyond the TIM element -- an
out-of-bounds read of adjacent skb/heap data when the TIM is the last
element in the frame. The +2 appears to account for the element id/len
header, but tim already points past that header at the element payload, so
the addend is wrong.
Pass the correct element end, (const u8 *)tim + tim_len.
Rosen Penev [Sun, 17 May 2026 04:27:16 +0000 (21:27 -0700)]
wifi: ath9k: Clear DMA descriptors without memset
Clear ath9k DMA descriptors with explicit status word stores instead of
memset(). The descriptor rings are 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 the descriptor status words so the compiler keeps
the clears as ordinary stores instead of folding them back into bulk
memset(). This covers AR9003 TX status descriptors as well as the RX
status area cleared when setting up RX descriptors.
Rosen Penev [Wed, 6 May 2026 23:48:48 +0000 (16:48 -0700)]
wifi: ath9k_htc: use module_usb_driver
This follows the pattern with other USB Wifi drivers. There is nothing
special being done in the _init and _exit functions here. Simplifies and
saves some lines of code.
wifi: wcn36xx: fix OOB read from short trigger BA firmware response
The firmware response length is only checked against sizeof(*rsp) (20
bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read
at buf + 20 without verifying the response contains it. This causes an
out-of-bounds read of stale heap data, corrupting the BA session state.
Add validation that the response includes the candidate data.
wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication
The firmware-controlled rsp->count field is used as the loop bound for
indexing into the flexible rsp->regs[] array without validation against
the message length. A count exceeding the actual data causes out-of-
bounds reads from the heap-allocated message buffer.
Add a check that count fits within the received message.
Fixes: 43efa3c0f241 ("wcn36xx: Implement print_reg indication") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260421135018.352774-3-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
wifi: wcn36xx: fix heap overflow from oversized firmware HAL response
The firmware response dispatcher copies all synchronous HAL responses
into the 4096-byte hal_buf without validating the response length. A
response exceeding WCN36XX_HAL_BUF_SIZE causes a heap buffer overflow
with firmware-controlled content.
Add a bounds check on the response length.
Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260421135018.352774-2-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
wifi: mac80211: Add 802.3 multicast encapsulation offload support
mac80211 converts 802.3 multicast packets to 802.11 format
before driver TX, even when Ethernet encapsulation offload
is enabled. This prevents drivers that support multicast
Ethernet encapsulation offload from receiving frames in
native 802.3 format.
Introduce the IEEE80211_OFFLOAD_ENCAP_MCAST flag to bypass the
802.11 encapsulation step and pass the multicast packet to the
driver in 802.3 format. Drivers that support multicast Ethernet
encapsulation offload can advertise this flag.
Disable multicast encapsulation offload in MLO case for drivers not
advertising MLO_MCAST_MULTI_LINK_TX support for AP mode and for
3-address AP_VLAN multicast packets.
wifi: mac80211: Add multicast to unicast support for 802.3 path
mac80211 already supports multicast-to-unicast conversion for
native 802.11 TX paths, but this handling is missing for the
802.3 transmit path. Due to that the packet never converted to
unicast and directly pass it to 802.11 Tx path by checking the
destination address as multicast.
Extend ieee80211_subif_start_xmit_8023() to honor the
multicast_to_unicast setting by cloning and converting multicast
Ethernet frames into per-station unicast transmissions, following
the same behavior of the native 802.11 TX path and allow it
to take 802.3 path.
wifi: mac80211: Add sta pointer sanity check in ieee80211_8023_xmit()
Currently ieee80211_8023_xmit() accesses the sta pointer without any
sanity check, assuming that only unicast packets for an authorized
station are processed. But the sta pointer could become NULL when
a framework to support 802.3 offload for the multicast packets is
added in the follow-up patches. Add the valid sta pointer sanity
check to avoid the invalid pointer access.
This aligns with some of the subordinate functions called by
ieee80211_8023_xmit() that already NULL-check 'sta' such as
ieee80211_select_queue() and ieee80211_aggr_check().
wifi: nl80211: Increase ie_len size to prevent truncated IEs in new peer notifications
Currently, ie_len in cfg80211_notify_new_peer_candidate is defined as
1-byte field, capping the maximum IE list size at 255 bytes. When a
large beacon is received, the IE list is truncated, passing incomplete
data to wpa_supplicant. This causes supplicant to fail parsing the IEs.
Increasing the size of ie_len to allow the full length of the IE list to
be forwarded properly.
Rosen Penev [Fri, 5 Jun 2026 00:56:27 +0000 (17:56 -0700)]
wifi: mac80211: fold tid_ampdu_rx allocations into a flexible array
Convert the separately-allocated reorder_buf pointer to a C99 flexible
array member at the end of struct tid_ampdu_rx, with both the
sk_buff_head and the jiffies timestamp in each array element. This
collapses three allocations into one and removes the corresponding
kfree() pairs from the error and free paths.
wifi: mac80211: Fix -Wc23-extensions in hwmp_route_info_get()
When building with a version of clang that supports
'-fms-anonymous-structs' (which will be used by the kernel instead of
the wider '-fms-extensions'), there are a couple warnings after some
recent mesg_hwmp.c changes:
net/mac80211/mesh_hwmp.c:373:3: error: label followed by a declaration is a C23 extension [-Werror,-Wc23-extensions]
373 | struct ieee80211_mesh_hwmp_preq_top *preq_elem_top =
| ^
net/mac80211/mesh_hwmp.c:390:3: error: label followed by a declaration is a C23 extension [-Werror,-Wc23-extensions]
390 | struct ieee80211_mesh_hwmp_prep_top *prep_elem_top =
| ^
2 errors generated.
Enclose the switch case blocks in braces to clear up the warning.
This pull request contains iwlwifi features and cleanups. Notably:
- Bump max core version for BZ/SC/DR to 106.
- Add KUnit tests for link grading, RSSI adjustment, and beacon
handling;
- Drop core101 support and remove TLC config v4/v5 compatibility code.
- Fixes:
Fix PCIe write pointer detection
Fix STEP_URM register address
Remove unneeded WoWLAN warning
reduce NIC wakeups during dump.
Revert MODULE_FIRMWARE relocation change
====================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
projects / linux / log