summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)AuthorFilesLines
2024-08-09wifi: rtw88: usb: Update the RX stats after every frameBitterblue Smith1-0/+1
Update the number of received unicast data frames and bytes every time a frame is received. This is what the PCI and SDIO drivers do. This has an influence on the power saving, bluetooth coexistence, and (in a future patch) the use of RX aggregation. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/75a2ca52-8f01-45c5-926f-d3a68ae3b284@gmail.com
2024-08-09wifi: rtw88: usb: Init RX burst length according to USB speedBitterblue Smith2-1/+28
This is needed in order to make USB RX aggregation work with RTL8811CU (and presumably RTL8822BU and RTL8822CU also). I don't know what BIT_DMA_BURST_CNT, BIT_DMA_MODE, and BIT_DROP_DATA_EN are doing. Tested with RTL8822CU, RTL8811CU, and RTL8723DU. The RX speed is unchanged in my tests. Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/ac569c6f-7129-4341-b523-901fe10cabff@gmail.com
2024-08-09wifi: rtl8xxxu: add missing rtl8192cu USB IDsPeter Robinson1-0/+6
The rtl8xxxu has all the rtl8192cu USB IDs except for the following 3 so add them to the untested section so they can be used with the rtl8xxxu as the rtl8192cu are well supported. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240806082233.3837436-1-pbrobinson@gmail.com
2024-08-09wifi: rtl8xxxu: drop reference to staging driversPeter Robinson1-3/+2
The Kconfig notes mention staging drivers that have since been removed so update the driver's description so it no longer references the staging rtl8723au and rtl8192u drivers which have now been deleted. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805221910.3765214-1-pbrobinson@gmail.com
2024-08-09wifi: rtw89: wow: add net-detect support for 8852cChin-Yen Lee1-1/+3
Enable net-detect in WoWLan stub of 8852c, and declare net-detect support up to 8 SSIDs. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-6-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: add delay option for net-detectChin-Yen Lee4-3/+27
The delay option is the period in unit of second for WoWLAN firmware to wait before the first scan. We get the option from cfg80211 and practice it. Another, in some platform, WoWLAN firmware may found configured network and then trigger resume process, before suspend process is completed, lead to the wakeup function failed. So the default value is set one to avoid the issue. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-5-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: add WoWLAN net-detect supportChin-Yen Lee9-78/+568
Net-detect is an option of WoWLAN to allow the device to be woken up from suspend mode when configured network is detected. When user enables net-detect and lets the device enter suspend state, WoWLAN firmware will periodically scan until beacon or probe response of configured networks are received. If configured networks are detected, WoWLAN firmware will trigger resume process. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-4-pkshih@realtek.com
2024-08-09wifi: rtw89: wow: implement PS mode for net-detectChin-Yen Lee4-7/+89
When net-detect is enabled, WoWLAN firmware will periodically scan until beacon or probe response of configured networks are received. To reduce power consumption, the FW-IPS mode is implemented to keep WiFi chip in idle mode between each scan. The FW-IPS is controlled by WoWLAN firmware to turn of some critical electrical components, and is different from the original IPS mode which most electrical components are turned off. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-3-pkshih@realtek.com
2024-08-09wifi: rtw89: 8852c: support firmware format up to v1Ping-Ke Shih1-2/+2
Driver has supported different WoWLAN reason code by commit 0e5210217768 ("wifi: rtw89: wow: update WoWLAN reason register for different FW") since firmware version 0.27.80.0. The old driver can't support two kinds of WoWLAN reason, so increase firmware format to v1. Also driver tables of BB and RF registers and power values will be added into v1 format. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240805090028.27768-2-pkshih@realtek.com
2024-08-07wifi: b43: Constify struct lpphy_tx_gain_table_entryChristophe JAILLET2-11/+11
'struct lpphy_tx_gain_table_entry' are not modified in this driver. Constifying this structure 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 16481 6232 0 22713 58b9 drivers/net/wireless/broadcom/b43/tables_lpphy.o After: ===== text data bss dec hex filename 22305 395 0 22700 58ac drivers/net/wireless/broadcom/b43/tables_lpphy.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-By: Michael Büsch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/e33bc9e6dff4a5b6cd8d0ab5399aa1abac5bef9d.1722753127.git.christophe.jaillet@wanadoo.fr
2024-08-07wifi: rtlwifi: rtl8192du: Initialise value32 in ↵Bitterblue Smith1-1/+1
_rtl92du_init_queue_reserved_page GCC complains: In file included from include/linux/ieee80211.h:21, from include/net/mac80211.h:20, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/../wifi.h:14, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:4: In function 'u32p_replace_bits', inlined from '_rtl92du_init_queue_reserved_page.isra' at drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:225:2: >> include/linux/bitfield.h:189:18: warning: 'value32' is used uninitialized [-Wuninitialized] Part of the variable is indeed left uninitialised. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202408062100.DWhN0CYH-lkp@intel.com/ Fixes: e769c67105d3 ("wifi: rtlwifi: Add rtl8192du/hw.{c,h}") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/2a808244-93d0-492c-b304-ae1974df5df9@gmail.com
2024-08-07wifi: ath12k: fix invalid AMPDU factor calculation in ath12k_peer_assoc_h_he()Baochen Qiang1-3/+2
Currently ampdu_factor is wrongly calculated in ath12k_peer_assoc_h_he(), fix it. This is found during code review. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240710021819.87216-1-quic_bqiang@quicinc.com
2024-08-07wifi: ath12k: match WMI BSS chan info structure with firmware definitionP Praneesh1-1/+1
struct wmi_pdev_bss_chan_info_event is not similar to the firmware struct definition, this will cause some random failures. Fix by matching the struct wmi_pdev_bss_chan_info_event with the firmware structure definition. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Signed-off-by: Karthikeyan Kathirvel <quic_kathirve@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240331183232.2158756-3-quic_kathirve@quicinc.com
2024-08-07wifi: ath12k: fix BSS chan info request WMI commandP Praneesh2-0/+2
Currently, the firmware returns incorrect pdev_id information in WMI_PDEV_BSS_CHAN_INFO_EVENTID, leading to incorrect filling of the pdev's survey information. To prevent this issue, when requesting BSS channel information through WMI_PDEV_BSS_CHAN_INFO_REQUEST_CMDID, firmware expects pdev_id as one of the arguments in this WMI command. Add pdev_id to the struct wmi_pdev_bss_chan_info_req_cmd and fill it during ath12k_wmi_pdev_bss_chan_info_request(). This resolves the issue of sending the correct pdev_id in WMI_PDEV_BSS_CHAN_INFO_EVENTID. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Signed-off-by: Karthikeyan Kathirvel <quic_kathirve@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240331183232.2158756-2-quic_kathirve@quicinc.com
2024-08-07wifi: ath12k: restore ASPM for supported hardwares onlyAditya Kumar Singh3-1/+9
During PCI based hardware device start up, ASPM is disabled for all. And once firmware is ready, it is restored back. However, not all hardwares (for example QCN9274) supports ASPM. Hence there is a need to conditionally restore ASPM back. Or else, for such hardwares, issue can be seen during sending and receiving packets. Introduce a new hardware param supports_aspm which identifies whether a given hardware supports ASPM or not and then accordingly restore it. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240709055817.3371406-1-quic_adisi@quicinc.com
2024-08-07wifi: ath9k: Remove error checks when creating debugfs entriesToke Høiland-Jørgensen2-4/+0
We should not be checking the return values from debugfs creation at all: the debugfs functions are designed to handle errors of previously called functions and just transparently abort the creation of debugfs entries when debugfs is disabled. If we check the return value and abort driver initialisation, we break the driver if debugfs is disabled (such as when booting with debugfs=off). Earlier versions of ath9k accidentally did the right thing by checking the return value, but only for NULL, not for IS_ERR(). This was "fixed" by the two commits referenced below, breaking ath9k with debugfs=off starting from the 6.6 kernel (as reported in the Bugzilla linked below). Restore functionality by just getting rid of the return value check entirely. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219122 Fixes: 1e4134610d93 ("wifi: ath9k: use IS_ERR() with debugfs_create_dir()") Fixes: 6edb4ba6fb5b ("wifi: ath9k: fix parameter check in ath9k_init_debug()") Reported-by: Daniel Tobias <dan.g.tob@gmail.com> Tested-by: Daniel Tobias <dan.g.tob@gmail.com> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240805110225.19690-1-toke@toke.dk
2024-08-07wifi: ath9k: use devm for gpio_request_one()Rosen Penev1-4/+2
Using devm_gpio_request_one() is simpler as then we don't need to call gpio_free(). Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240731210312.7622-1-rosenp@gmail.com
2024-08-07wifi: ath9k: use devm for request_irq()Rosen Penev2-11/+5
Avoids having to manually call free_irq(). Simplifies code slightly. Signed-off-by: Rosen Penev <rosenp@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240731210243.7467-1-rosenp@gmail.com
2024-08-07wifi: rtw89: correct VHT TX rate on 20MHz connectionDian-Syuan Yang1-2/+5
It may get wrong bitrate when connecting to AP set VHT 20MHz, and thus we fix it to follow Wi-Fi spec. Signed-off-by: Dian-Syuan Yang <dian_syuan0116@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-6-pkshih@realtek.com
2024-08-07wifi: rtw89: add support for HW encryption in unicast management framesKuan-Chung Chen10-15/+40
Add hardware encryption support for unicast management frames for 8922AE and 8852CE. Other chips will continue to use software encryption for unicast management frames. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-5-pkshih@realtek.com
2024-08-07wifi: rtw89: avoid to add interface to list twice when SERChih-Kang Chang2-1/+21
If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: <TASK> ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]--- Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-4-pkshih@realtek.com
2024-08-07wifi: rtw89: 8922a: Add new fields for scan offload H2C commandPo-Hao Huang4-6/+28
Update scan offload H2C format to fit firmware version 35.21. The new fields indicate lengths of variable length members, so when driver and firmware are using mismatch version, FW could handle the parsing better. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-3-pkshih@realtek.com
2024-08-07wifi: rtw89: 8922a: new implementation for RFK pre-notify H2CKuan-Chung Chen3-22/+53
For firmware version 0.35.31 and above, update H2C RFK pre-notify to new implementation. Rename existing H2C to v0 for backward compatibility. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240731070506.46100-2-pkshih@realtek.com
2024-08-05wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850Baochen Qiang4-0/+83
In transmit path, it is likely that the iova is not aligned to PCIe TLP max payload size, which is 128 for WCN7850. Normally in such cases hardware is expected to split the packet into several parts in a manner such that they, other than the first one, have aligned iova. However due to hardware limitations, WCN7850 does not behave like that properly with some specific unaligned iova in transmit path. This easily results in target hang in a KPI transmit test: packet send/receive failure, WMI command send timeout etc. Also fatal error seen in PCIe level: ... Capabilities: ... ... DevSta: ... FatalErr+ ... ... ... Work around this by manually moving/reallocating payload buffer such that we can map it to a 128 bytes aligned iova. The moving requires sufficient head room or tail room in skb: for the former we can do ourselves a favor by asking some extra bytes when registering with mac80211, while for the latter we can do nothing. Moving/reallocating buffer consumes additional CPU cycles, but the good news is that an aligned iova increases PCIe efficiency. In my tests on some X86 platforms the KPI results are almost consistent. Since this is seen only with WCN7850, add a new hardware parameter to differentiate from others. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Cc: <stable@vger.kernel.org> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240715023814.20242-1-quic_bqiang@quicinc.com
2024-08-04wifi: brcmsmac: clean up unnecessary current_ampdu_cnt and related checksDmitry Kandybka1-21/+1
In 'brcms_c_ffpld_check_txfunfl()', 'current_ampdu_cnt' is hardcoded to zero, so 'txunfl_ratio' is always zero as well and some dead code can be removed. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240801101531.6626-1-d.kandybka@gmail.com
2024-08-04wifi: brcmfmac: introducing fwil query functionsArend van Spriel5-28/+48
When the firmware interface layer was refactored it provided various "get" and "set" functions. For the "get" in some cases a parameter needed to be passed down to firmware as a key indicating what to "get" turning the output parameter of the "get" function into an input parameter as well. To accommodate this the "get" function blindly copies the parameter which in some places resulted in an uninitialized warnings from the compiler. These have been fixed by initializing the input parameter in the past. Recently another batch of similar fixes were submitted to address clang static checker warnings [1]. Proposing another solution by introducing a "query" variant which is used when the (input) parameter is needed by firmware. The "get" variant will only fill the (output) parameter with the result received from firmware taking care of proper endianess conversion. [1] https://lore.kernel.org/all/20240702122450.2213833-1-suhui@nfschina.com/ Fixes: 81f5dcb80830 ("brcmfmac: refactor firmware interface layer.") Reported-by: Su Hui <suhui@nfschina.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240727185617.253210-1-arend.vanspriel@broadcom.com
2024-08-04wifi: brcmfmac: fwsignal: Use struct_size() to simplify brcmf_fws_rxreorder()Christophe JAILLET2-8/+4
In the "struct brcmf_ampdu_rx_reorder", change the 'pktslots' field into flexible array. It saves the size of a pointer when the memory is allocated and avoids an indirection when the array is used. It also removes the usage of a pointer arithmetic and saves a few lines of code. Finally, struct_size() can be used. It is not a must have here, because it is easy to see that buf_size can not overflow, but still, it is a good practice. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/f4ca6b887ca1290c71e76247218adea4d1c42442.1721547559.git.christophe.jaillet@wanadoo.fr
2024-08-04wifi: mwifiex: add host mlme for AP modeDavid Lin8-3/+309
Add host based MLME to enable WPA3 functionalities in AP mode. This feature required a firmware with the corresponding V2 Key API support. The feature (WPA3) is currently enabled and verified only on IW416. Also, verified no regression with change when host MLME is disabled. Signed-off-by: David Lin <yu-hao.lin@nxp.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240704033001.603419-3-yu-hao.lin@nxp.com
2024-08-04wifi: mwifiex: add host mlme for client modeDavid Lin15-14/+683
Add host based MLME to enable WPA3 functionalities in client mode. This feature required a firmware with the corresponding V2 Key API support. The feature (WPA3) is currently enabled and verified only on IW416. Also, verified no regression with change when host MLME is disabled. Signed-off-by: David Lin <yu-hao.lin@nxp.com> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240704033001.603419-2-yu-hao.lin@nxp.com
2024-08-04wifi: mwifiex: increase max_num_akm_suitesSascha Hauer1-0/+2
The maximum number of AKM suites will be set to two if not specified by the driver. Set it to CFG80211_MAX_NUM_AKM_SUITES to let userspace specify up to ten AKM suites in the akm_suites array. Without only the first two AKM suites will be used, further ones are ignored. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20240530130156.1651174-1-s.hauer@pengutronix.de
2024-08-02wifi: rtw89: pass chanctx_idx to rtw89_btc_{path_}phymap()Zong-Zhe Yang7-37/+39
Originally, rtw89_btc_phymap() and rtw89_btc_path_phymap() access chan with hard-code RTW89_CHANCTX_0. But, they are problematic when the chip supports multiple channels. So, change their prototype and pass chanctx_idx ahead. Let callers still pass RTW89_CHANCTX_0 for now, but we will refine callers in the following. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-8-pkshih@realtek.com
2024-08-02wifi: rtw89: fw: correct chan access in assoc_cmac_tbl_g7 and update_beacon_beZong-Zhe Yang1-2/+2
Originally, these H2C commands access chan with hard-code RTW89_CHANCTX_0. They are problematic when the chip supports multiple channels. So, correct them by accessing right chan under rtwvif. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-7-pkshih@realtek.com
2024-08-02wifi: rtw89: pass rtwvif to RFK scanZong-Zhe Yang8-16/+24
For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_scan prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-6-pkshih@realtek.com
2024-08-02wifi: rtw89: pass rtwvif to RFK channelZong-Zhe Yang9-17/+18
For chips supporting multiple channels, they need to get target info from rtwvif, e.g. PHY index and Chanctx index. So, change rfk_channel prototype and pass rtwvif ahead. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-5-pkshih@realtek.com
2024-08-02wifi: rtw89: rename sub_entity to chanctxZong-Zhe Yang24-223/+223
Originally, we planed to fill MAC_0/1 indicators with chanctx and use sub_entity_xxx for these things. However, there are some reasons listed below which make us give up this plan after we know our Wi-Fi 7 HW design. 1. one link is bound to one HW band during its life time but, one link might change chanctx dynamically 2. in concurrent mode, assume 1st vif is MLD 1st vif's 2nd link might use the same chanctx as 2nd vif but, they are not on the same HW band So, we let sub_entity_xxx stuffs deal with only chanctx now. And, to be more readable, we rename sub_entity related words to chanctx. No logic is changed. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-4-pkshih@realtek.com
2024-08-02wifi: rtw89: mcc: stop at a role holding chanctxZong-Zhe Yang3-6/+38
In general, MCC (multi-channel concurrency) stops when some chanctx is unassigned. Originally, we let FW to stop at a fixed role. However, it might be the one to be unassigned. So, iterate MCC roles and select one which is still holding chanctx. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-3-pkshih@realtek.com
2024-08-02wifi: rtw89: chan: refine MCC re-plan flow when unassign chanctxZong-Zhe Yang1-12/+25
Originally during unassign-chanctx, MCC (multi-channel concurrency) is re-planed before set-channel if need. But, we might calculate MCC stuffs based on old channel info. And, the following set-channel might be racing with FW MCC state mechanism. So, we refine this flow. Now, if MCC re-plan is needed here, it will be done after set-channel. Besides, to be more rigorous, we now ensure entity isn't paused before we deal with MCC things here. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240727080650.12195-2-pkshih@realtek.com
2024-08-02wifi: rtw88: always wait for both firmware loading attemptsDmitry Antipov1-3/+4
In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN. Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Reported-by: syzbot+6c6c08700f9480c41fe3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6c6c08700f9480c41fe3 Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240726114657.25396-1-dmantipov@yandex.ru
2024-08-02wifi: rtw89: fix typo of rtw89_phy_ra_updata_XXXZong-Zhe Yang3-7/+7
`updata` should be `update` Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-5-pkshih@realtek.com
2024-08-02wifi: rtw89: 885xb: reset IDMEM mode to prevent download firmware failurePing-Ke Shih1-1/+1
For different firmware type, it could change IDMEM mode, so reset it to default to avoid encountering error for RTL8851B/RTL8852B/RTL8852BT if that kind of firmware was downloaded before. rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 5 rtw89_8851be 0000:02:00.0: Firmware version 0.29.41.3, cmd version 0, type 3 rtw89_8851be 0000:02:00.0: MAC has already powered on rtw89_8851be 0000:02:00.0: fw security fail rtw89_8851be 0000:02:00.0: download firmware fail rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x1E0 = 0x62 rtw89_8851be 0000:02:00.0: [ERR]fwdl 0x83F2 = 0x8 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f500 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f51c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f520 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f534 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f508 rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f53c rtw89_8851be 0000:02:00.0: [ERR]fw PC = 0xb892f524 rtw89_8851be 0000:02:00.0: failed to setup chip information rtw89_8851be: probe of 0000:02:00.0 failed with error -16 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-4-pkshih@realtek.com
2024-08-02wifi: rtw89: add support for hardware rfkillKuan-Chung Chen10-0/+184
Add support for ieee80211::rfkill_poll ops. This enables periodic monitoring of the hardware rfkill state, triggering updates when the status changes. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-3-pkshih@realtek.com
2024-08-02wifi: rtw89: add EVM statistics for 1SS rateKuan-Chung Chen4-13/+52
To more accurately debug performance issues, EVM statistics will differentiate between different space streams, and only beacon and data frames will be included. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724052626.12774-2-pkshih@realtek.com
2024-08-02wifi: rtw88: 8822c: Parse channel from IE to correct invalid hardware reportsPo-Hao Huang7-3/+63
For CCK packets we could get incorrect reports from hardware. And this causes wrong frequencies being reported. Parse the channel information from IE if provided by AP to fix this. Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240724050501.7550-1-pkshih@realtek.com
2024-08-01wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()Dmitry Kandybka1-2/+2
In 'ath9k_get_et_stats()', promote TX stats counters to 'u64' to avoid possible integer overflow. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240725111743.14422-1-d.kandybka@gmail.com
2024-08-01wifi: ath9k: Use swap() to improve ath9k_hw_get_nf_hist_mid()Thorsten Blum1-5/+2
Use the swap() macro to simplify the ath9k_hw_get_nf_hist_mid() function and improve its readability. Fixes the following Coccinelle/coccicheck warning reported by swap.cocci: WARNING opportunity for swap() Compile-tested only. Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/20240710185743.709742-2-thorsten.blum@toblux.com
2024-08-01wifi: ath9k: use unmanaged PCI functions in ath9k_pci_owl_loaderHeiner Kallweit1-5/+3
Only managed PCI resource in the driver is the iomapped bar. However the bar is unmapped in the same function. Therefore using the device-managed versions just causes overhead, w/o any benefit. Once this is switched to the non-managed versions, there's nothing left to be managed for pcim_enable_device(). Therefore we can reduce overhead here too and switch to the non-managed version as well. This includes removing the no longer needed call to pcim_pin_device(). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Link: https://patch.msgid.link/3b46f6c7-4372-4cc9-9a7c-2c1c06d29324@gmail.com
2024-07-31wifi: rtw88: 8703b: Fix reported RX band widthBitterblue Smith1-1/+1
The definition of GET_RX_DESC_BW is incorrect. Fix it according to the GET_RX_STATUS_DESC_BW_8703B macro from the official driver. Tested only with RTL8812AU, which uses the same bits. Cc: stable@vger.kernel.org Fixes: 9bb762b3a957 ("wifi: rtw88: Add definitions for 8703b chip") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Tested-by: Fiona Klute <fiona.klute@gmx.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1cfed9d5-4304-4b96-84c5-c347f59fedb9@gmail.com
2024-07-31wifi: rtw88: 8822c: Fix reported RX band widthBitterblue Smith1-4/+6
"iw dev wlp2s0 station dump" shows incorrect rx bitrate: tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2 rx bitrate: 86.7 MBit/s VHT-MCS 9 VHT-NSS 1 This is because the RX band width is calculated incorrectly. Fix the calculation according to the phydm_rxsc_2_bw() function from the official drivers. After: tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2 rx bitrate: 390.0 MBit/s VHT-MCS 9 80MHz VHT-NSS 1 It also works correctly with the AP configured for 20 MHz and 40 MHz. Tested with RTL8822CE. Cc: stable@vger.kernel.org Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/bca8949b-e2bd-4515-98fd-70d3049a0097@gmail.com
2024-07-31wifi: rtw89: 8852bt: add 8852BE-VT to Makefile and KconfigPing-Ke Shih2-0/+23
RTL8852BE-VT is a WiFi 6 2x2 chip, which can operate on 2/5 GHz channels and 80MHz bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-8-pkshih@realtek.com
2024-07-31wifi: rtw89: 8852bte: add PCI entry of 8852BE-VTPing-Ke Shih1-0/+93
PCI device ID 10ec:b520 of RTL8852BE-VT is added as PCI entry, and define chip capabilities for driver common routines. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240720021340.12102-7-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 14:20:23 +0000