summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-09wifi: mt76: mt7925: pass WCID explicitly to mt7925_mcu_sta_ba()Sean Wang
mt7925_mcu_sta_ba() currently hides the BA target behind an implicit WCID lookup. Pass the WCID explicitly so the caller controls which BA context is being programmed. No functional change intended. 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-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: keep TX BA state in the primary WCIDSean Wang
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>
2026-06-09wifi: mt76: mt7925: add MT7927 USB supportSean Wang
Add the MT7927 USB device ID and normalize the raw 0x6639 CHIPID to MT7927 so the shared mt7925u code can use the proper chip-specific paths. Restore the required band setup after USB MAC reset before restarting the device. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-22-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: add MT7927 PCIe supportSean Wang
Add the missing MT7927 device support in the mt7925 PCI path. This ensures MT7927 is identified correctly and uses the proper initialization flow. 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-21-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt792x: enable CNM ops for MT7927Sean Wang
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. 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-20-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: add MBMC event handlingSean Wang
Handle MBMC unsolicited events from firmware to report the current MBMC state. This helps validate MT7927 band setup. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425195011.790265-19-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: sync MT7927 BSS band assignmentSean Wang
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 Wang
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 Wang
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 Wang
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 Wang
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 Wang
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 Wang
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 Wang
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 Tia
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 Tia
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 Tia
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 Tia
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 Tia
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 Tia
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 Tia
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 Tia
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 Tia
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 Bianconi
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 Wittmayer
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 Fietkau
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 Fietkau
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 Hovold
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 Hovold
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 Hovold
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 Hovold
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 Hovold
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 Gupta
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 peerElXreno
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 encapElXreno
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 Ven
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 Zeng
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 Penev
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 Pak
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-09platform: arm64: qcom-hamoa-ec: Fix indentation in comment tablesShawn Guo
With tab=8 (Linux Kernel coding style), there are a couple of lines misaligned in the comment ASCII tables. Fix indentation for them. Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> Link: https://patch.msgid.link/20260608082348.92575-1-shengchao.guo@oss.qualcomm.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-09platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)Krishna Chomal
The HP Omen 16-ap0xxx (board ID: 8E35) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_legacy_thermal_params. Testing on board 8E35 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Ahmet Öztürk <sivasli-ahmet@gmx.de> Reported-by: Ahmet Öztürk <sivasli-ahmet@gmx.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221523 Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260608134255.36280-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-09drm/virtio: Fix driver removal with disabled KMSDmitry Osipenko
DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS. Fixes: 72122c69d717 ("drm/virtio: Add option to disable KMS support") Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Link: https://patch.msgid.link/20260604122743.13383-1-dmitry.osipenko@collabora.com
2026-06-09Merge tag 'imx-soc-updates-for-v7.2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/arm i.MX Soc Changes for v7.2 - Fix IIM mapping leak in imx31 revision check - Fix CCM node reference leak in imx3 - Make scmi_imx_misc_ctrl_nb variable static in firmware driver * tag 'imx-soc-updates-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux: ARM: imx31: Fix IIM mapping leak in revision check ARM: imx3: Fix CCM node reference leak firmware: imx: sm-misc: Make scmi_imx_misc_ctrl_nb variable static Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-06-09r8152: handle the return value of usb_reset_device()Chih Kai Hsu
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-09i2c: imx-lpi2c: fix resource leaks switching to devm_dma_request_chan()Carlos Song
The LPI2C driver requests DMA channels using dma_request_chan(), but never releases them in lpi2c_imx_remove(), resulting in DMA channel leaks every time the driver is unloaded. Additionally, when lpi2c_dma_init() successfully requests the TX DMA channel but fails to request the RX DMA channel, the probe falls back to PIO mode and completes successfully. Since probe succeeds, the devres framework will not trigger any cleanup, leaving the TX DMA channel and the memory allocated for the dma structure held for the lifetime of the device even though DMA is never used. Switch to devm_dma_request_chan() to let the device core manage DMA channel lifetime automatically. Wrap all allocations within a devres group so that devres_release_group() can release all partially acquired resources when DMA init fails and probe continues in PIO mode. Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C") Signed-off-by: Carlos Song <carlos.song@nxp.com> Cc: <stable@vger.kernel.org> # v6.14+ Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20260520093323.2882070-1-carlos.song@oss.nxp.com
2026-06-09platform/x86: msi-ec: Add support for MSI Pulse GL66 12th GenLuis de Carlos
Add the firmware string '1583EMS1.109' to the ALLOWED_FW_10 array. This enables Embedded Controller support, including battery charge thresholds, for the MSI Pulse GL66 12UEK (MS-1583) laptop. Signed-off-by: Luis de Carlos <reskoldo73@gmail.com> Link: https://patch.msgid.link/20260527134750.25263-1-reskoldo73@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-09platform/x86: dell-laptop: add Inspiron N5110 to touchpad LED quirk tableGleb Sonichev
The Inspiron N5110 needs the touchpad LED quirk (Vostro V130 quirk) to properly control the touchpad LED. Add its DMI identifier to the existing quirk table, next to the similar Inspiron M5110 entry. Tested on Dell Inspiron N5110. The touchpad LED works correctly with this quirk enabled. Signed-off-by: Gleb Sonichev <sonichev555@gmail.com> Acked-by: Pali Rohár <pali@kernel.org> Link: https://patch.msgid.link/20260525100047.20046-1-sonichev555@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-09platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8D26)Krishna Chomal
The HP Omen 16-ap0xxx (board ID: 8D26) has the same WMI interface as other Victus S boards, but requires quirks for correctly switching thermal profile. Add the DMI board name to victus_s_thermal_profile_boards[] table and map it to omen_v1_legacy_thermal_params. Testing on board 8D26 confirmed that platform profile is registered successfully and fan RPMs are readable and controllable. Tested-by: Alberto Escaño <alberto_e_88@yahoo.es> Reported-by: Alberto Escaño <alberto_e_88@yahoo.es> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221514 Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260525102226.56300-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-09platform/x86/intel/pmc: rate-limit LTR scale-factor warningMike Bommarito
convert_ltr_scale() emits an unconditional pr_warn() whenever an LTR row encoded by hardware has a scale-factor field of 6 or 7 (reserved values per the PCIe LTR ECN). The function is called twice per LTR row (snoop + non-snoop) by pmc_core_ltr_show(), which is invoked on every read of /sys/kernel/debug/pmc_core/ltr_show as well as during certain platform driver activity. On a Meteor Lake laptop with an Intel AX210 Wi-Fi card, this produces 4-12 "Invalid LTR scale factor." lines per second in dmesg, with no context to help identify which PMC IP / row carries the bad value. Switch to pr_warn_once() so the warning still flags the spec violation once per boot, and include the offending scale value in the message. Identifying the originating LTR row would require restructuring the caller's loop to perform the validity check itself; that is left as a separate change. Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Mike Bommarito <michael.bommarito@gmail.com> Link: https://patch.msgid.link/20260523114517.101305-1-michael.bommarito@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-06-09platform/x86: hp-wmi: Add thermal support for board 8B2Fyahia ahmed
Added thermal support for board ID 8B2F. Signed-off-by: yahia ahmed <yahia.a.abdrabou@gmail.com> Link: https://patch.msgid.link/20260522203418.28784-1-yahia.a.abdrabou@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-15 19:26:25 +0000