summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2025-05-16wifi: ath10k: Constify structures in hw.cChristophe JAILLET
Structures defined in hw.c are not modified in this driver. Constifying these structures moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 10357 951 0 11308 2c2c drivers/net/wireless/ath/ath10k/hw.o After: ===== text data bss dec hex filename 11125 203 0 11328 2c40 drivers/net/wireless/ath/ath10k/hw.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/504b4d5276d13f5f9c3bffcfdaf244006312c22b.1745051315.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-16wifi: ath10k: Fix spelling mistake "comple" -> "complete"Colin Ian King
There is a spelling mistake in a ath10k_warn message. Fix it and remove space before colon to tidy up message. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20250418115627.534833-1-colin.i.king@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-16wifi: ath12k: Use scan link ID 15 for all scan operationsAditya Kumar Singh
According to the code documentation in ath12k_mac_op_hw_scan(), "if no links of an ML VIF are already active on the radio corresponding to the given scan frequency, the scan link (link ID 15) should be used". This rule should apply to non-ML interfaces as well to maintain uniformity across the driver. However, currently, link 0 is selected as the scan link during non-ML operations. Update the code to use scan link ID 15 in all cases. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250417-fix_scan_vdev_handling-v3-2-9ec42513d26b@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-16wifi: ath12k: handle scan link during vdev createAditya Kumar Singh
For scanning purposes, the driver can use link ID 15 (scan link). A future change will make non-ML interfaces to select the scan link. In this scenario, arvif->link_id will be used to retrieve the link configuration in ath12k_mac_vdev_create(). However, link ID 15 is not recognized as a valid link ID in the upper kernel, which will result in a failure to fetch link_conf and subsequently cause the scan to fail. To avoid this issue, ensure link_conf is fetched only when the link ID is within the valid range. Since link_conf cannot be retrieved using the scan link, use vif->addr as the Ethernet address for creating the scan vdev. This address will serve as the source address (address 2) in the probe request frames during scanning. Additionally, use the automatic Tx power value for the vdev. As this is a scan vdev, these values do not affect the scan functionality. Note that vif->addr will only be taken when a valid link_conf can not be fetched. Otherwise, link_conf's address will be taken as address 2. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250417-fix_scan_vdev_handling-v3-1-9ec42513d26b@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-16wifi: ath12k: read country code from SMBIOS for WCN7850Wen Gong
Read the country code from SMBIOS and send it to the firmware. The firmware will then indicate the regulatory domain information for the country code, which ath12k will use. dmesg: [ 1242.637253] ath12k_pci 0000:02:00.0: worldwide regdomain setting from SMBIOS [ 1242.637259] ath12k_pci 0000:02:00.0: bdf variant name not found. [ 1242.637261] ath12k_pci 0000:02:00.0: SMBIOS bdf variant name not set. [ 1242.927543] ath12k_pci 0000:02:00.0: set current country pdev id 0 alpha2 00 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-02582-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kang Yang <kang.yang@oss.qualcomm.com> Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250417024227.1712-1-kang.yang@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-05-16Merge tag 'rtw-next-2025-05-16' of https://github.com/pkshih/rtwJohannes Berg
Ping-Ke Shih says: ================== rtw-next patches for v6.16 Some fixes and refinements across drivers, and regular development of MLO and STA + P2P concurrency. Major changes are listed below. rtw88: * improve throughput for RTL8814AU rtw89: * support MLO * improve user experience for STA + P2P concurrency * dynamic antenna gain (DAG) with different power by antenna * load SAR tables from ACPI ================== Link: https://patch.msgid.link/17e74675-70cc-43d7-a797-afb937030d34@RTEXMBS04.realtek.com.tw/ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-16wifi: rtw89: fix firmware scan delay unit for WiFi 6 chipsChin-Yen Lee
The scan delay unit of firmware command for WiFi 6 chips is microsecond, but is wrong set now and lead to abnormal work for net-detect. Correct the unit to avoid the error. Fixes: e99dd80c8a18 ("wifi: rtw89: wow: add delay option for net-detect") Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250513125203.6858-1-pkshih@realtek.com
2025-05-16wifi: rtw88: fix the 'para' buffer size to avoid reading out of boundsAlexey Kodanev
Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], &para[1])', which reads 5 bytes: void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4)); Detected using the static analysis tool - Svace. Fixes: 4136214f7c46 ("rtw88: add BT co-existence support") Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250513121304.124141-1-aleksei.kodanev@bell-sw.com
2025-05-16wifi: rtw89: mcc: avoid redundant recalculations if no chance to improveZong-Zhe Yang
MCC will track the changes of beacon offset, and trigger a recalculation when the difference is larger than the tolerance. It means that a better pattern is expected after recalculating. However, in the cases which get a worse beacon offset, there is no chance to improve the pattern even if recalculating. So, bypass them. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250511035217.10410-7-pkshih@realtek.com
2025-05-16wifi: rtw89: mcc: deal with non-periodic NoAZong-Zhe Yang
Originally, MCC just took periodic NoA into account. When the connected GO announces non-periodic NoA and GC side is during MCC, sometimes GC cannot receive beacons well if the MCC scheduling conflicts with the non-periodic NoA planning. After the loss exceeds the tolerable amount, beacon filter will report connection loss. However, in this case, the loss is acceptable. So now, MCC will calculate the range of non-periodic NoA. And then, don't care beacon loss during the range. Besides, rtw89_mcc_fill_role_limit() only makes sense for GC. Remove the redundant check of GO. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250511035217.10410-6-pkshih@realtek.com
2025-05-16wifi: rtw89: mcc: introduce calculation of anchor patternZong-Zhe Yang
In the cases that two MCC roles' TBTTs are too close or too far, original MCC pattern calculation logic will lead to a result that both roles might not cover its TBTT with sufficient time. Introduce a new calculation logic called anchor pattern for these corner cases. It allows to choose one role as anchor to put its TBTT in the middle of its duration directly. For now, a P2P role has a higher priority to be chosen as an anchor. Then, if able, another role might need to depend on courtesy mechanism to take time from anchor. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250511035217.10410-5-pkshih@realtek.com
2025-05-16wifi: rtw89: mcc: add courtesy mechanism conditions to P2P rolesZong-Zhe Yang
In one enablement of courtesy mechanism, there is one provider and one receiver. And, receiver can use the provider's time in a given period. But, to make P2P NoA protocol work as expected as possible, GO should be present at the time it doesn't announce absent, and GC should not use the time when GO announces absent. So, don't enable courtesy mechanism if provider is GO or receiver is GC. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250511035217.10410-4-pkshih@realtek.com
2025-05-16wifi: rtw89: mcc: drop queued chanctx changes when stoppingZong-Zhe Yang
When MCC is about to stop, there may be some chanctx changes which are queued for work but have not yet been run. To avoid these changes from being processed in a wrong state (e.g. next new MCC instance), cancel the queued work and drop queued changes. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250511035217.10410-3-pkshih@realtek.com
2025-05-16wifi: rtw89: mcc: pass whom to stop at when pausing chanctxZong-Zhe Yang
When stopping MCC, FW can stop at a given MCC role following H2C command. When pausing chanctx during MCC, in general, the caller expects to process things with its chanctx. So, pass the caller as target and let FW stop MCC at it. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250511035217.10410-2-pkshih@realtek.com
2025-05-16wifi: rtw88: Fix the random "error beacon valid" messages for USBBitterblue Smith
All the USB devices have a problem in AP mode: uploading the updated beacon to the chip's reserved page can randomly fail: [34996.474304] rtw88_8723du 1-2:1.2: error beacon valid [34996.474788] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [34999.956369] rtw88_8723du 1-2:1.2: error beacon valid [34999.956846] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [34999.956855] rtw88_8723du 1-2:1.2: failed to download beacon [35017.978296] rtw88_8723du 1-2:1.2: error beacon valid [35017.978805] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [35017.978823] rtw88_8723du 1-2:1.2: failed to download beacon [35023.200395] rtw88_8723du 1-2:1.2: error beacon valid [35023.200869] rtw88_8723du 1-2:1.2: failed to download drv rsvd page [35023.200875] rtw88_8723du 1-2:1.2: failed to download beacon [35478.680547] rtw88_8723du 1-2:1.2: error beacon valid [35478.681023] rtw88_8723du 1-2:1.2: failed to download drv rsvd page Disable some beacon-related hardware functions before uploading the beacon and enable them again after. Tested with RTL8723DU, RTL8812BU, RTL8822CE. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c248c40a-d432-47ed-90e0-d81ee6c32464@gmail.com
2025-05-16wifi: rtw88: usb: Upload the firmware in bigger chunksBitterblue Smith
RTL8811AU stops responding during the firmware download on some systems: [ 809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0 [ 812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0 [ 837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110 [ 867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110 [ 868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode [ 897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110 Maybe it takes too long when writing the firmware 4 bytes at a time. Write 196 bytes at a time for RTL8821AU, RTL8811AU, and RTL8812AU, and 254 bytes at a time for RTL8723DU. These are the sizes used in their official drivers. Tested with all these chips. Cc: stable@vger.kernel.org Link: https://github.com/lwfinger/rtw88/issues/344 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/43f1daad-3ec0-4a3b-a50c-9cd9eb2c2f52@gmail.com
2025-05-16wifi: rtw88: usb: Reduce control message timeout to 500 msBitterblue Smith
RTL8811AU stops responding during the firmware download on some systems: [ 809.256440] rtw_8821au 5-2.1:1.0: Firmware version 42.4.0, H2C version 0 [ 812.759142] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: renamed from wlan0 [ 837.315388] rtw_8821au 1-4:1.0: write register 0x1ef4 failed with -110 [ 867.524259] rtw_8821au 1-4:1.0: write register 0x1ef8 failed with -110 [ 868.930976] rtw_8821au 5-2.1:1.0 wlp48s0f4u2u1: entered promiscuous mode [ 897.730952] rtw_8821au 1-4:1.0: write register 0x1efc failed with -110 Each write takes 30 seconds to fail because that's the timeout currently used for control messages in rtw_usb_write(). In this scenario the firmware download takes at least 2000 seconds. Because this is done from the USB probe function, the long delay makes other things in the system hang. Reduce the timeout to 500 ms. This is the value used by the official USB wifi drivers from Realtek. Of course this only makes things hang for ~30 seconds instead of ~30 minutes. It doesn't fix the firmware download. Tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8814AU, RTL8811AU, RTL8812AU, RTL8821AU, RTL8723DU. Cc: stable@vger.kernel.org Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Link: https://github.com/lwfinger/rtw88/issues/344 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1e35dd26-3f10-40b1-b2b4-f72184a26611@gmail.com
2025-05-16wifi: rtw89: pci: enlarge retry times of RX tag to 1000Ping-Ke Shih
RX tag is sequence number to ensure RX DMA is complete. On platform Gigabyte X870 AORUS ELITE WIFI7, sometimes it needs longer retry times to complete RX DMA, or driver throws warnings and connection drops: rtw89_8922ae 0000:07:00.0: failed to update 162 RXBD info: -11 rtw89_8922ae 0000:07:00.0: failed to update 163 RXBD info: -11 rtw89_8922ae 0000:07:00.0: failed to update 32 RXBD info: -11 rtw89_8922ae 0000:07:00.0: failed to release TX skbs Fixes: 0bc7d1d4e63c ("wifi: rtw89: pci: validate RX tag for RXQ and RPQ") Reported-by: Samuel Reyes <zohrlaffz@gmail.com> Closes: https://lore.kernel.org/linux-wireless/f4355539f3ac46bbaf9c586d059a8cbb@realtek.com/T/#t Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250509013433.7573-1-pkshih@realtek.com
2025-05-16wifi: rtw89: leave idle mode when setting WEP encryption for AP modeDian-Syuan Yang
Due to mac80211 triggering the hardware to enter idle mode, it fails to install WEP key causing connected station can't ping successfully. Currently, it forces the hardware to leave idle mode before driver adding WEP keys. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250507031203.8256-1-pkshih@realtek.com
2025-05-16wifi: rtw89: pci: configure manual DAC mode via PCI config API onlyPing-Ke Shih
To support 36-bit DMA, configure chip proprietary bit via PCI config API or chip DBI interface. However, the PCI device mmap isn't set yet and the DBI is also inaccessible via mmap, so only if the bit can be accessible via PCI config API, chip can support 36-bit DMA. Otherwise, fallback to 32-bit DMA. With NULL mmap address, kernel throws trace: BUG: unable to handle page fault for address: 0000000000001090 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 71 Comm: irq/26-pciehp Tainted: G OE 6.14.2-061402-generic #202504101348 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE RIP: 0010:rtw89_pci_ops_write16+0x12/0x30 [rtw89_pci] RSP: 0018:ffffb0ffc0acf9d8 EFLAGS: 00010206 RAX: ffffffffc158f9c0 RBX: ffff94865e702020 RCX: 0000000000000000 RDX: 0000000000000718 RSI: 0000000000001090 RDI: ffff94865e702020 RBP: ffffb0ffc0acf9d8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000015 R13: 0000000000000719 R14: ffffb0ffc0acfa1f R15: ffffffffc1813060 FS: 0000000000000000(0000) GS:ffff9486f3480000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001090 CR3: 0000000090440001 CR4: 00000000000626f0 Call Trace: <TASK> rtw89_pci_read_config_byte+0x6d/0x120 [rtw89_pci] rtw89_pci_cfg_dac+0x5b/0xb0 [rtw89_pci] rtw89_pci_probe+0xa96/0xbd0 [rtw89_pci] ? __pfx___device_attach_driver+0x10/0x10 ? __pfx___device_attach_driver+0x10/0x10 local_pci_probe+0x47/0xa0 pci_call_probe+0x5d/0x190 pci_device_probe+0xa7/0x160 really_probe+0xf9/0x370 ? pm_runtime_barrier+0x55/0xa0 __driver_probe_device+0x8c/0x140 driver_probe_device+0x24/0xd0 __device_attach_driver+0xcd/0x170 bus_for_each_drv+0x99/0x100 __device_attach+0xb4/0x1d0 device_attach+0x10/0x20 pci_bus_add_device+0x59/0x90 pci_bus_add_devices+0x31/0x80 pciehp_configure_device+0xaa/0x170 pciehp_enable_slot+0xd6/0x240 pciehp_handle_presence_or_link_change+0xf1/0x180 pciehp_ist+0x162/0x1c0 irq_thread_fn+0x24/0x70 irq_thread+0xef/0x1c0 ? __pfx_irq_thread_fn+0x10/0x10 ? __pfx_irq_thread_dtor+0x10/0x10 ? __pfx_irq_thread+0x10/0x10 kthread+0xfc/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x47/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Fixes: 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address") Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Closes: https://lore.kernel.org/linux-wireless/ccaf49b6-ff41-4917-90f1-f53cadaaa0da@gmail.com/T/#u Closes: https://github.com/openwrt/openwrt/issues/17025 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250506015356.7995-1-pkshih@realtek.com
2025-05-15Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.15-rc7). Conflicts: tools/testing/selftests/drivers/net/hw/ncdevmem.c 97c4e094a4b2 ("tests/ncdevmem: Fix double-free of queue array") 2f1a805f32ba ("selftests: ncdevmem: Implement devmem TCP TX") https://lore.kernel.org/20250514122900.1e77d62d@canb.auug.org.au Adjacent changes: net/core/devmem.c net/core/devmem.h 0afc44d8cdf6 ("net: devmem: fix kernel panic when netlink socket close after module unload") bd61848900bf ("net: devmem: Implement TX path") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-15Merge tag 'iwlwifi-next-2025-05-15' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== iwlwifi features, notably a rework of the transport configuration ==================== Link: https://patch.msgid.link/MW5PR11MB5810DD2655DE461E98A618DDA390A@MW5PR11MB5810.namprd11.prod.outlook.com/ Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-05-15wifi: mt76: mt7925: fix missing hdr_trans_tlv command for broadcast wtblMing Yen Hsieh
Ensure that the hdr_trans_tlv command is included in the broadcast wtbl to prevent the IPv6 and multicast packet from being dropped by the chip. Cc: stable@vger.kernel.org Fixes: cb1353ef3473 ("wifi: mt76: mt7925: integrate *mlo_sta_cmd and *sta_cmd") Reported-by: Benjamin Xiao <fossben@pm.me> Tested-by: Niklas Schnelle <niks@kernel.org> Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://lore.kernel.org/lkml/EmWnO5b-acRH1TXbGnkx41eJw654vmCR-8_xMBaPMwexCnfkvKCdlU5u19CGbaapJ3KRu-l3B-tSUhf8CCQwL0odjo6Cd5YG5lvNeB-vfdg=@pm.me/ Link: https://patch.msgid.link/20250509010421.403022-1-mingyen.hsieh@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-15wifi: mt76: disable napi on driver removalFedor Pchelkin
A warning on driver removal started occurring after commit 9dd05df8403b ("net: warn if NAPI instance wasn't shut down"). Disable tx napi before deleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: <TASK> mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e Tested with mt7921e but the same pattern can be actually applied to other mt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabled in their *_dma_init() functions and only toggled off and on again inside their suspend/resume/reset paths. So it should be okay to disable tx napi in such a generic way. Found by Linux Verification Center (linuxtesting.org). Fixes: 2ac515a5d74f ("mt76: mt76x02: use napi polling for tx cleanup") Cc: stable@vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Tested-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com> Link: https://patch.msgid.link/20250506115540.19045-1-pchelkin@ispras.ru Signed-off-by: Felix Fietkau <nbd@nbd.name>
2025-05-15wifi: iwlwifi: mld: allow 2 ROCs on the same vifMiri Korenblit
In the current code, if an ROC is started on a vif that already has an active ROC we reject it and warn. But really there is no such limitation. The actual limitation is to not have 2 ROCs of the same type simultaneously. Add a helper function to find a vif that has an active ROC of a given type, and only if one exist - reject the ROC. This allows also to remove bss_roc_vif. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.1f8c55198578.I17cb191596ed4e97a4854108f8ca5ca197662a62@changeid
2025-05-15wifi: iwlwifi: fw: api: include required headers in rs/locationJohannes Berg
Various headers are required for these to build properly. Include the needed files. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.956281013349.I4c537dffb82f5e5042e4a880cde3c6da38a56cbc@changeid
2025-05-15wifi: iwlwifi: rename ctx-info-gen3 to ctx-info-v2Miri Korenblit
Context info was introduced in 22000, and was significantly changed in ax210. The new version of context info was called 'gen3', probably because in 22000, the gen2 transport was added. But this name is just wrong: - if 'gen' enumerates transports, there was not a gen3 transport, just a few modifications to gen1/2 transports needed for ax210. - if 'gen' enumerates devices, then we can just use the device names. Also, context info will soon become a lib, agnostic of the transport generations. Simply replace 'gen3' with 'v2'. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.a580bd8d4f74.Ie413a02233f1a5ad538e13071c09760b9d97be3b@changeid
2025-05-15wifi: iwlwifi: fix a wrong commentMiri Korenblit
iwl_pcie_apply_destination is used in all generation. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.7eaf79a07226.I615cfd21001208b366c94a5fcb8e30a7d97f0ac2@changeid
2025-05-15wifi: iwlwifi: map iwl_context_info to the matching structMiri Korenblit
Map iwl_context_info to the matching struct in the FW. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.a7240935006e.I75e2e13421b5dac2c1bdbd01fdfd34c38f2d3d8c@changeid
2025-05-15wifi: iwlwifi: remove unused macroMiri Korenblit
TFD_QUEUE_SIZE_MAX_GEN3 is not used, remove it. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.a0154cca6afb.Ifb4915e0acd51be6a75d33a8b96b3f7b0928b312@changeid
2025-05-15wifi: iwlwifi: unify iwlagn_scd_bc_tbl_entry and iwl_gen3_bc_tbl_entryMiri Korenblit
As those are now the same, unify and adjust the documentation. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.b7ddfade8fec.I2bf97252c4bd751077ade204767eed02d815614d@changeid
2025-05-15wifi: iwlwifi: use bc entries instead of bc table also for pre-ax210Miri Korenblit
iwlagn_scd_bc_tbl is used for pre-ax210 devices, and iwl_gen3_bc_tbl_entry is used for ax210 and on. But there is no difference between the the 22000 version and the AX210+ one. In order to unify the two, as first step make iwlagn_scd_bc_tbl an entry as well, and adjust the code. In a later patch both structures will be unified. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.645cd82ebf48.Iaa7e88179372d60ef31157e379737b5babe54012@changeid
2025-05-15wifi: iwlwifi: remove GEN3 from a couple of macrosMiri Korenblit
'GEN3' here really means 'AX210'. Rename. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.b7fb5b854ded.Ib52b84c6e36e312b2eeb84a3cf71c6185fb52ee7@changeid
2025-05-15wifi: iwlwifi: use normal versioning convention for iwl_tx_cmdMiri Korenblit
We have iwl_tx_cmd for devices older than 22000, iwl_tx_cmd_gen2 for 22000 devices, and iwl_tx_cmd_gen3 ax210 and up. But the convention for all other APIs is to have the latest version without any prefix and the older ones - with a _vX prefix, where X is the highest version that this struct support. The term 'gen' was introduced as the name of the (back then) new transport, and should not be used as a device name (for that we have the actual names: 22000, ax210, etc.) Now as a new transport, called 'gen3', is going to be written and it can be confused with this API. Move iwl_tx_cmd to use the regular versioning convention. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.806e40c8f767.Ibc0e95e43a6fa6d47f72823bf804314d5db84618@changeid
2025-05-15wifi: iwlwifi: stop supporting TX_CMD_API_S_VER_8Miri Korenblit
This version is not used on any device. Don't support it. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2025-05-13wifi: iwlwifi: cfg: reduce configuration struct sizeJohannes Berg
We don't need the CORES() match nor jacket (which really doesn't even make sense to match to the RF anyway), and since the subdevice masks we care about are contiguous, we can encode them as highest and lowest bit set (automatically.) By encoding whether to match or not as separate flags and taking advantage of the limited range of the RF type, step and ID we can reduce the amount of memory needed for the table, while also making the logic (apart perhaps from the subdevice mask) easier to understand. This reduces the size of the module by about 1.5KiB on x86-64. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.38a805a7c96f.Ieece00476cea6054b0827cd075eb8ba5943373df@changeid
2025-05-12wifi: iwlwifi: cfg: clean up dr/br configsJohannes Berg
We don't need the configs that won't end up being used, such as the "br" config for discrete devices, remove them. Also remove the module firmware for test chips, that's never needed. For now keep the iwl_dr_mac_cfg even if it's unused, we'll add platforms with it once we have their PCI IDs. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.15e2056ec40f.I75a6ce4ad0b14d2b4413615f05523a8f62f08954@changeid
2025-05-12wifi: iwlwifi: Add helper function to extract device IDPagadala Yesu Anjaneyulu
Add iwl_trans_get_device_id() to extract the device ID from the hw_id member in the iwl_trans structure. hw_id member contains both sub-device ID and device ID, with the device ID occupying bits 16 to 31. Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.4411402701f2.I81cde20de05e3bb993977f8d4bbf90707819347f@changeid
2025-05-12wifi: iwlwifi: cfg: mark Ty devices as discreteJohannes Berg
Looks like these were never marked discrete, since they always used the iwl_so_mac_cfg (earlier iwl_so_trans_cfg). Mark them as discrete since they are. Signed-off-by: Johannes Berg <johannes.berg@intel.com> PerCI-Ready: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250511195137.f3a75ae80f28.I79964f4426389f04798b70841a9e847be48bf9c3@changeid
2025-05-12wifi: iwlwifi: cfg: remove MAC type/step matchingJohannes Berg
Now that it's all split into MAC and RF configs, remove the matching on MAC type and step. If we ever need to do something based on the MAC step, we'll have to find some new mechanism (since the MAC type is known already from the PCI IDs table, but not the step), or just handle the (likely small) differences in code. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.fca99a5ab315.Iae27b781221fd29845493adf2c29d9e4f7a9c33b@changeid
2025-05-12wifi: iwlwifi: cfg: add a couple of older devicesJohannes Berg
There are some devices that are misidentified, such as 7265-N and Killer 1435 variants. Add their names, and for some of them also add the PCI IDs to match at all. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.ca03a90c294e.I04d64964c664d49ab16760d754968f09c607f36a@changeid
2025-05-12wifi: iwlwifi: cfg: fix PE RF namesJohannes Berg
There are a couple of variants of this, match them correctly to their names and clean up a bit. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.d03eaad5be56.I276a09f0cad364e51ed4730ca81fbe504e61f2c7@changeid
2025-05-12wifi: iwlwifi: cfg: fix and clean up FM/WH device matchingJohannes Berg
We only need a few entries, and there don't seem to be any such devices actually limited to 160 MHz. Also add PCI IDs for the new Killer device on LNL platforms. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.ba2964bee671.If7aaaf10b236115e39b17d37296341de6c821069@changeid
2025-05-12wifi: iwlwifi: cfg: clean up GF device matchingJohannes Berg
Again some names don't actually exist, and we only need a few entries to cover Ty (discrete) and AX211/AX411. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.8888f6798581.If332ebfc3b3f4a335a79ccee13e90f93b1ee4df7@changeid
2025-05-12wifi: iwlwifi: cfg: clean up JF device matchingJohannes Berg
This really only needs to be distinguished based on the RF type, bandwidth limit and possibly diversity (JF1). Some of the names that are defined don't even exist. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.bca83604aa92.I35301d2d8b57c072284fff7bf6682b4a9424e56c@changeid
2025-05-12wifi: iwlwifi: tests: make subdev match test more preciseJohannes Berg
It's OK to match with subdevice_mask as long as that doesn't overlap the RF ID/BW limit/cores fields in that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.87cc0ad360a8.I9be361caedd7258e8e817d4100c549681396f307@changeid
2025-05-12wifi: iwlwifi: cfg: clean up HR device matchingJohannes Berg
We only need a few entries on top of the Killer ones. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.fa0cde465de0.I6a3f9ed9a7341e2c58c69af50a9f126992a745f2@changeid
2025-05-12wifi: iwlwifi: cfg: unify and add some Killer devicesJohannes Berg
Unify a number of Killer devices now that we no longer need to distinguish the MAC type, and add a few more that wouldn't have gotten the right name before. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.a16b1c2740f8.I147b97ef2c8e99451806ea0e34a9eb5bff37c326@changeid
2025-05-12wifi: iwlwifi: cfg: fix and unify Killer/JF configsJohannes Berg
All of these should be 160 MHz, and they can be recognised by just the subdevice ID. Unify all the Killer/JF entries. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.a93788f159ec.I114f09a0f61849ac3b75d12d7def35be842e5b7c@changeid
2025-05-12wifi: iwlwifi: cfg: fix Ma device configsJohannes Berg
These should be according to their RF type, not just use GF unconditionally. Fix that. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250510214621.4dd365eb76cd.I91f368df691a3ce6c545d9cdc44676e7883efa16@changeid
generated by cgit (git 2.34.1) at 2025-07-31 08:04:50 +0000