summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2024-11-06wifi: ath12k: add multi-link flag in peer create commandSriram R
Driver should indicate to firmware whether a peer is multi-link or not in peer create command using multi-link flag. Add changes to support WMI_TAG_MLO_PEER_CREATE_PARAMS in WMI_PEER_CREATE_CMDID. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241101151705.165987-7-kvalo@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: ath12k: Add helpers for multi link peer creation and deletionSriram R
Add helper functions for multi link peer addition and deletion. And add address validation to ensure we are not creating link peers (belonging to different clients) with same MLD address. To aid in this validation for faster lookup, add a new list of ML peers to struct ath12k_hw::ml_peers and use the same for parsing for the above address validation use cases. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241101151705.165987-6-kvalo@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: ath12k: introduce ath12k_hw_warn()Kalle Valo
In the following patch we need to use ath12k_warn() but don't easily have access to struct ath12k_base (ab) but do have access to struct ath12k_hw (ah). So add a new warning helper ath12_hw_warn() which takes the latter but the log output is still identical but uses the struct device pointer stored to struct ath12k_hw. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241101151705.165987-5-kvalo@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: ath12k: Refactor sta state machineSriram R
Refactor ath12k_mac_op_sta_state(), with generic wrappers which can be used for both multi link stations and non-ML stations. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241101151705.165987-4-kvalo@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: ath12k: MLO vdev bringup changesSriram R
Add changes to add the link vdevs dynamically whenever a channel is assigned from mac80211 for a link vdev. During vdev create, update ML address of the vdev to firmware using the new WMI parameter (WMI_TAG_MLO_VDEV_CREATE_PARAMS). During vdev start, notify the firmware that this link vdev is newly added and also indicate all its known partners so that the firmware can take necessary actions to internally update the partners on the new link being added. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Co-developed-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Rameshkumar Sundaram <quic_ramess@quicinc.com> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241101151705.165987-3-kvalo@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: ath12k: ath12k_mac_vdev_create(): use goto for error handlingKalle Valo
In commit 477cabfdb776 ("wifi: ath12k: modify link arvif creation and removal for MLO") I had accidentally left one personal TODO comment about using goto instead of ret. Switch to use goto to be consistent with the error handling in the function. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241101151705.165987-2-kvalo@kernel.org Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: ath12k: mark QMI driver event helpers as noinlineJeff Johnson
As described in [1], compiling the ath12k driver using clang with KASAN enabled warns about some functions with excessive stack usage, with the worst case being: drivers/net/wireless/ath/ath12k/qmi.c:3546:13: warning: stack frame size (2456) exceeds limit (1024) in 'ath12k_qmi_driver_event_work' [-Wframe-larger-than] Nathan [2] highlighted work done by Arnd [3] to address similar issues in other portions of the kernel. ath12k_qmi_driver_event_work() itself is a pretty lightweight function, but it dispatches to several other functions which do the real work: ath12k_qmi_driver_event_work() ath12k_qmi_event_server_arrive() ath12k_qmi_host_cap_send() ath12k_qmi_event_mem_request() ath12k_qmi_respond_fw_mem_request() ath12k_qmi_event_load_bdf() ath12k_qmi_request_target_cap() ath12k_qmi_load_bdf_qmi() ath12k_qmi_wlanfw_m3_info_send() Mark all of those underlying functions as 'noinline_for_stack' to prevent them from being inlined in ath12k_qmi_driver_event_work(), thereby eliminating the excessive stack usage. Link: https://msgid.link/bc214795-1c51-4cb7-922f-67d6ef98bff2@quicinc.com # [1] Link: https://msgid.link/20241025223321.GA3647469@thelio-3990X # [2] Link: https://lore.kernel.org/all/?q=f:arnd@kernel.org+Wframe-larger-than # [3] Acked-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241028-ath12k_qmi_driver_event_work-v1-1-0d532eb593fa@quicinc.com Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: ath11k: Suspend hardware before firmware mode off for WCN6750Balaji Pothunoori
During rmmod, the ath11k host driver sends a QMI MODE OFF command to firmware. As part of this command, firmware initiates WLAN de-initialization and accesses certain UMAC registers during this process. Currently, on WCN6750 WLAN hardware, the system is in a sleep state when firmware receives the QMI MODE OFF command. This results in a firmware/hardware reset while accessing the UMAC hardware registers during sleep state. To avoid this, add logic to send WCN6750 hardware specific WMI_PDEV_SUSPEND_AND_DISABLE_INTR command to firmware prior to sending the QMI MODE OFF command. This will cause firmware to cease all activities and put the device in a powered-on state that prevents access to registers which have been powered off. Signed-off-by: Balaji Pothunoori <quic_bpothuno@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://patch.msgid.link/20241029083340.3010798-1-quic_bpothuno@quicinc.com Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
2024-11-06wifi: rtlwifi: Remove some exhalbtc deadcodeDr. David Alan Gilbert
exhalbtc_rf_status_notify(), exhalbtc_coex_dm_switch() and exhalbtc_antenna_detection() are unused since they were added in 2017's commit 7937f02d1953 ("rtlwifi: btcoex: hook external functions for newer chips") Remove them. This leaves ex_btc8723b1ant_coex_dm_reset() unused. Remove it. exhalbtc_dbg_control(), exhalbtc_stack_update_profile_info(), exhalbtc_set_hci_version(), and exhalbtc_set_bt_patch_version() are unused since their addition in 2014 by commit aa45a673b291 ("rtlwifi: btcoexist: Add new mini driver") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241104144331.29262-1-linux@treblig.org
2024-11-06wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failuresGuilherme G. Piccoli
Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000. Cc: stable@vger.kernel.org # v6.1+ Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com
2024-11-06wifi: rtw88: Enable the new RTL8821AU/RTL8812AU driversBitterblue Smith
These are older Wifi 5 chips. RTL8821AU is 1x1, with or without Bluetooth. RTL8812AU is 2x2, without Bluetooth. Beamforming is not implemented. It looks like these chips need a different implementation than what is in bf.c. Speed tests with RTL8821AU: 137 Mbps download, 144 Mbps upload. Speed tests with RTL8812AU: 344 Mbps download, 387 Mbps upload. Station mode and AP mode were tested. Bluetooth coexistence works. I used my Bluetooth headphones for several days, listening to music and watching videos. There is only a problem with the wifi speeds with one router: With ISP's HG6544C router: Official driver: 3/5 Mbps. rtw88: a bit more, but not steady at all. Not enough to watch a 1080p Youtube video. With my D-Link Eagle R32 router running Openwrt, on the same channel: Official driver: 6/10 Mbps. rtw88: download starts around 30, climbs to 50 / upload is 10 Mbps. I can watch a 1080p Youtube video. The music doesn't cut out during any speed tests. I also tested transferring files to and from my phone. I don't have other types of Bluetooth devices to test. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/0b8e8093-8103-4999-86bf-0055ec52ea64@gmail.com
2024-11-06wifi: rtw88: Add rtw8821au.c and rtw8812au.cBitterblue Smith
These are the entry points for the new modules rtw88_8821au (RTL8821AU/RTL8811AU) and rtw88_8812au (RTL8812AU). Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/91c495f8-a607-429b-8bc0-5a45d3c1393e@gmail.com
2024-11-06wifi: rtw88: Add rtw8812a.{c,h}Bitterblue Smith
These contain code specific to RTL8812AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/a0057683-79eb-4ab2-8f74-11a3bc58adfb@gmail.com
2024-11-06wifi: rtw88: Add rtw8821a.{c,h}Bitterblue Smith
These contain code specific to RTL8821AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/37218648-ada7-4fad-b7bd-d2aee28cefb9@gmail.com
2024-11-06wifi: rtw88: Add rtw88xxa.{c,h}Bitterblue Smith
These contain code shared by both RTL8821AU and RTL8812AU chips. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/b8590382-a954-412d-a96b-63e360b97acc@gmail.com
2024-11-06wifi: rtw88: Add rtw8821a_table.{c,h}Bitterblue Smith
These contain various arrays for initialising RTL8821AU. Also TX power limits. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/087c7260-fcc3-4e22-886b-ac477cad9198@gmail.com
2024-11-06wifi: rtw88: Add rtw8812a_table.{c,h}Bitterblue Smith
These contain various arrays for initialising RTL8812AU. Also TX power limits. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/086f476c-e832-4867-963c-a64a63252fd6@gmail.com
2024-11-06wifi: rtw89: coex: set higher priority to BT when WL scan and BT A2DP existChing-Te Ku
If WiFi operation channel & scan channel both at 2.4GHz, original will keep going at WL > BT priority table for a long time. It makes A2DP can not sent audio data to SUT device in time then performed a lag audio. Assign a BT > WL priority table when A2DP exist, to avoid the issue. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241031023032.7102-1-pkshih@realtek.com
2024-11-06wifi: rtw89: 8852b: change RF mode to normal mode when set channelChih-Kang Chang
Set the RF mode from 0xA(low power mode) to 0x3(Normal mode) to avoid abnormal TX waveform in OFDM rate. Originally the RF mode will be changed to normal mode by the firmware after entering LPS once. Therefore, this change does not affect power saving. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030091603.6073-1-pkshih@realtek.com
2024-11-06wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()Pei Xiao
kmalloc may fail, return value might be NULL and will cause NULL pointer dereference. Add check NULL return of kmalloc in btc_fw_set_monreg(). Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Fixes: b952cb0a6e2d ("wifi: rtw89: coex: Add register monitor report v7 format") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/516a91f3997534f708af43c7592cbafdd53dd599.1730253508.git.xiaopei01@kylinos.cn
2024-11-06wifi: rtw89: 8922a: fill the missing OP1dB configurationKuan-Chung Chen
OP1dB stands for Output 1dB Compression Point. At this point, the power amplifier starts to enter the saturation region, resulting in distortion. The configuration of OP1dB can optimize the RX gain saturation region, improving RX throughput from 573 to 675 Mbps. Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022903.13243-1-pkshih@realtek.com
2024-11-06wifi: rtw89: mac: no configure CMAC/DMAC tables for firmware secure bootPing-Ke Shih
The initial CMAC/DMAC tables used by WiFi 6 chips are not needed to be called for firmware secure boot. Otherwise, it causes firmware abnormal and throw warnings. rtw89_8852be 0000:03:00.0: FW status = 0x1400 rtw89_8852be 0000:03:00.0: FW BADADDR = 0xb872f800 rtw89_8852be 0000:03:00.0: FW EPC/RA = 0xb89333b7 rtw89_8852be 0000:03:00.0: FW MISC = 0x0 rtw89_8852be 0000:03:00.0: R_AX_HALT_C2H = 0x10002010 rtw89_8852be 0000:03:00.0: R_AX_SER_DBG_INFO = 0x0 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c95 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9b rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9d rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c97 rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c9f rtw89_8852be 0000:03:00.0: [ERR]fw PC = 0xb89a2c99 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-9-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: use common function to parse security section for WiFi 6 chipsPing-Ke Shih
The MSSC (multiple security section count) can be regular number (shown in below figure) or 0xFF (supported already). For WiFi 7 or newer WiFi 6 chips, the MSSC will be 0xFF. But early WiFi 6 chip such as RTL8852B could be either one of the cases. Extend __parse_security_section() to support both with/without secure boot mode accordingly. +---------------------------+ -\ | firmware header | | | | | | +-----------------------+ | | | | section type/size * N | | | | +-----------------------+ | | +---------------------------+ -/ : : +---------------------------+ -\ | secure section type (ID:9)| | | | | +----|-> [ security key data ] | | | +---------------------------+ -/ | |MSS Pool for above section | | | [ security key data 1 ] | +----|- [ security key data 2 ] | by mss_idx | [ security key data 3 ] | | ... M | * M = MSSC (MSSC != 0xFF) +---------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-8-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: move v1 MSSC out of __parse_security_section() to share with v0Ping-Ke Shih
The security section can be a common parser for v0 and v1 format of firmware header, so move retrieval code of v1 MSSC from the function, and then sharing becomes possible. Not logic change at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-7-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: set recorded IDMEM share mode in firmware header to registerPing-Ke Shih
For WiFi 6 chips, firmware secure boot will run on a IDMEM mode specified in firmware header. Retrieve the mode from firmware, and set to registers accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-6-pkshih@realtek.com
2024-11-06wifi: rtw89: fw: shrink download size of security section for RTL8852BPing-Ke Shih
For RTL8852B, when current firmware is secure boot, the security section needs a special treatment that shrink its size to 960. As figure below, not only shrink the amount of download size of security section (2), but also need to modify the section size in firmware header (1) that is also downloaded to chip. +---------------------------+ | firmware header | | | | +-----------------------+ | | | section type, size N -|-|-------+ | | ... (1) | | | | +-----------------------+ | | +---------------------------+ | 2048 shrink to 960 : : | +---------------------------+ -\ | | security section type 9 | | | | (2) | | <--+ | | | +---------------------------+ -/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-5-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: read firmware secure info v0 from efuse for WiFi 6 chipsPing-Ke Shih
WiFi 6 chips could program secure information in v0 or v1 format. Use existing v1 parser or newly added v0 parser to recognize firmware key that is going to be used. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-4-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: move recognize firmware MSS info v1 to commonPing-Ke Shih
The WiFi 6 chip use the same firmware MSS information v1 read from efuse, so move this logic to common. No change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-3-pkshih@realtek.com
2024-11-06wifi: rtw89: efuse: move reading efuse of fw secure info to commonPing-Ke Shih
The secure key used by certain hardware module is programmed in efuse, so driver should read the information from efuse before downloading firmware. Originally only RTL8922AE can support firmware secure boot, and read efuse during chip power on. To extend to support all chips, move the caller to common power on flow and add separate functions to read efuse for WiFi 6 chips. No logic change at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241030022135.11688-2-pkshih@realtek.com
2024-11-01wifi: rtw89: set pause_data field to avoid transmitting data in scan channelsChih-Kang Chang
Set pause_data to all of the scan channels, excluding the OP channel, to prevent data frame transmission to the scan channels, which causes retransmission. Additionally, this flag won't affect the transmission of probe requests from the scan channels. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241026022143.7304-1-pkshih@realtek.com
2024-11-01wifi: rtw89: don't check done-ack for entering PSChin-Yen Lee
In WoWLAN mode, driver will disable interrupt after calling H2C command for entering PS mode, but it may lead to failing to enter deep PS mode by firmware because the done-ack of the H2C from firmware is not handled by driver. In fact, the done-ack for entering PS is not necessary for driver to check, so remove it. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241024055509.8000-1-pkshih@realtek.com
2024-10-31Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.12-rc6). Conflicts: drivers/net/wireless/intel/iwlwifi/mvm/mld-mac80211.c cbe84e9ad5e2 ("wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd") 188a1bf89432 ("wifi: mac80211: re-order assigning channel in activate links") https://lore.kernel.org/all/20241028123621.7bbb131b@canb.auug.org.au/ net/mac80211/cfg.c c4382d5ca1af ("wifi: mac80211: update the right link for tx power") 8dd0498983ee ("wifi: mac80211: Fix setting txpower with emulate_chanctx") drivers/net/ethernet/intel/ice/ice_ptp_hw.h 6e58c3310622 ("ice: fix crash on probe for DPLL enabled E810 LOM") e4291b64e118 ("ice: Align E810T GPIO to other products") ebb2693f8fbd ("ice: Read SDP section from NVM for pin definitions") ac532f4f4251 ("ice: Cleanup unused declarations") https://lore.kernel.org/all/20241030120524.1ee1af18@canb.auug.org.au/ No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-31wifi: cw1200: Fix potential NULL dereferenceLinus Walleij
A recent refactoring was identified by static analysis to cause a potential NULL dereference, fix this! Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202410121505.nyghqEkK-lkp@intel.com/ Fixes: 2719a9e7156c ("wifi: cw1200: Convert to GPIO descriptors") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241028-cw1200-fix-v1-1-e092b6558d1e@linaro.org
2024-10-31wifi: brcm80211: Remove unused dma_txflush()Dr. David Alan Gilbert
dma_fxflush() has been unused since 2013's commit 7b2385b95363 ("brcmsmac: rework of mac80211 .flush() callback operation") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241025204651.244627-1-linux@treblig.org
2024-10-31wifi: wfx: Fix error handling in wfx_core_init()Yuan Can
The wfx_core_init() returns without checking the retval from sdio_register_driver(). If the sdio_register_driver() failed, the module failed to install, leaving the wfx_spi_driver not unregistered. Fixes: a7a91ca5a23d ("staging: wfx: add infrastructure for new driver") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/20241022090453.84679-1-yuancan@huawei.com
2024-10-31Merge tag 'ath-next-20241030' of ↵Kalle Valo
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath ath.git patches for v6.13 This development cycle featured phase 1 of patches to ath12k to support the new 802.11be MLO feature, along with other ath12k feature patches. In older drivers, support for some additional devices were added. And there was the usual set of bug fixes and cleanups across most drivers. Per-driver highlights: ath12k * Switch to using wiphy_lock() and remove ar->conf_mutex * Convert struct ath12k_sta::update_wk to use struct wiphy_work * Add phase 1 of 802.11be MLO support * Add firmware coredump collection support * Add debugfs support for a multitude of statistics * Fix host representation of multiple hal_rx structs * Fix use-after-free in ath12k_dp_cc_cleanup() * Skip Rx TID cleanup for self peer * Fix warning and crash when unloading in a VM * Convert CE interrupt handling from tasklet to BH workqueue * Fix A-MSDU indication in monitor mode ath11k * Fix double free issue during SRNG deinit * Enable firmware diagnostic events for WCN6750 * Fix CE offset address calculation for WCN6750 during SSR * Fix stack frame size warning in ath11k_vif_wow_set_wakeups() * Document the inputs for ath11k on WCN6855 ath10k * Fix multiple stack frame size warnings * Fix invalid VHT parameters in supported_vht_mcs_rate_nss* structs * Avoid NULL pointer error during SDIO remove ath5k * Add support for Arcadyan ARV45XX AR2417 & Gigaset SX76[23] AR241[34]A
2024-10-30wifi: iwlwifi: replace deprecated PCI functionsPhilipp Stanner
pcim_iomap_table() and pcim_iomap_regions_request_all() have been deprecated by the PCI subsystem in commit e354bb84a4c1 ("PCI: Deprecate pcim_iomap_table(), pcim_iomap_regions_request_all()"). Replace these functions with their successors, pcim_iomap() and pcim_request_all_regions(). Link: https://lore.kernel.org/r/20241030112743.104395-7-pstanner@redhat.com Signed-off-by: Philipp Stanner <pstanner@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Kalle Valo <kvalo@kernel.org>
2024-10-29wifi: rtw88: 8812a: Mitigate beacon lossBitterblue Smith
The RTL8812AU has a reception problem, maybe only in the 5 GHz band. Sometimes, in some positions, it stops receiving anything even though the distance to the AP is only ~3 meters and there are no obstacles. Moving it a few centimeters fixes it. Switch the initial gain to maximum coverage when there is beacon loss. This only helps sometimes. This is similar to what the official driver does. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/203f5043-4fe1-4f35-8b8f-d3b6f44e1fd9@gmail.com
2024-10-29wifi: rtw88: 8821a: Regularly ask for BT info updatesBitterblue Smith
The RTL8821AU firmware sends C2H_BT_INFO by itself when bluetooth headphones are connected, but not when they are disconnected. This leads to the coexistence code still using the A2DP algorithm long after the headphones are disconnected, which means the wifi speeds are much lower than they should be. Work around this by asking for updates every two seconds if the chip is RTL8821AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/358acdd2-6aae-46c1-9c66-fcce4e700b96@gmail.com
2024-10-29wifi: rtw88: coex: Support chips without a scoreboardBitterblue Smith
All the chips currently supported have a "scoreboard": the chip keeps track of certain things related to bluetooth, for example, whether bluetooth is active. The information can be read from register 0xaa. RTL8821AU doesn't have this. Implement bluetooth activity detection in rtw_coex_monitor_bt_enable() based on the bluetooth TX/RX counters. This is mostly important for RTL8811AU, the version of RTL8821AU without bluetooth. Without this change, the driver thinks bluetooth is active and the wifi speeds are low. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/5058f23d-2086-42cd-82ad-eef31a348467@gmail.com
2024-10-29wifi: rtw88: Detect beacon loss with chips other than 8822cBitterblue Smith
The driver is supposed to avoid entering LPS (power saving) when there is beacon loss, but only RTL8822C detects the beacon loss (because it has beacon filtering in the firmware). Detect beacon loss with the other chips by checking if we received less than half the expected number of beacons in the last 2-second interval. This gets rid of the occasional "failed to get tx report from firmware" warnings with RTL8821AU. It may also avoid some disconnections. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/f52b2fcf-bf94-48bc-89bd-e55ebc3a2f2d@gmail.com
2024-10-29wifi: rtw88: usb: Set pkt_info.ls for the reserved pageBitterblue Smith
"ls" meaning "last segment". Without this RTL8812AU can't upload the reserved page in USB 2 mode. (Somehow it's fine in USB 3 mode.) Also tested with RTL8822CU, RTL8812BU, RTL8811CU, RTL8723DU, RTL8811AU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/e443f5d9-4b53-4f64-985c-64313ec80bef@gmail.com
2024-10-29wifi: rtw88: Move pwr_track_tbl to struct rtw_rfe_defBitterblue Smith
RTL8812AU uses one set of TX power tracking tables for RFE 3, and another set for everything else. Move pwr_track_tbl from struct rtw_chip_info to struct rtw_rfe_def in order to load the right set of tables for each RFE (RF front end) type. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/904d0ab1-c046-40cd-a3a3-d4fdcf663c9d@gmail.com
2024-10-29wifi: rtw88: Support TX page sizes bigger than 128Bitterblue Smith
All the chips supported so far have a TX page size of 128 bytes. Change the type of the page_size member of struct rtw_chip_info from u8 to u16 in order to support RTL8821AU (page size of 256 bytes) and RTL8812AU (page size of 512 bytes). Also change the types of several related variables and function parameters from u8 to u16. The TX page size is used, among other things, to construct the beacon, null data, QOS null data, and PS poll templates which are uploaded to the chip's reserved page. Each template needs to be aligned on a multiple of the TX page size. Power saving can't work if the TX page size is wrong. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/acdefbb1-3daf-4349-9e03-9472754d5f1e@gmail.com
2024-10-29wifi: rtw88: Make txagc_remnant_ofdm an arrayBitterblue Smith
txagc_remnant_ofdm member of struct rtw_dm_info should be different for each RF path, so make it an array of size RTW_RF_PATH_MAX (4). Until now all the chips using this had only one RF path, but RTL8812AU has two, and RTL8814AU has four. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/68571ba9-e504-4b2d-bfa1-62f468753649@gmail.com
2024-10-29wifi: rtw88: Enable data rate fallback for older chipsBitterblue Smith
RTL8811AU fails to perform the 4-way handshake when the AP is too far because it transmits the EAPOL frames at MCS9 and when that doesn't work it retries 48 times with the same rate, to no avail. Retrying 48 times with the same rate seems pointless. Set the appropriate field in the TX descriptor to allow it to use lower rates when retrying. Set it for RTL8723D and RTL8703B because they interpret this field the same way as RTL8811A. The newer RTL8822C, RTL8822B, RTL8821C seem to interpret this field in the TX descriptor differently, so leave it alone for those chips. Tested with RTL8811AU and RTL8723DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/2b3e3e6f-541b-4a3b-8ca3-65b267e6a95a@gmail.com
2024-10-29wifi: rtw88: Let each driver control the power on/off processBitterblue Smith
RTL8821AU and RTL8812AU have to do some things differently, so let them have full control. The other chips use the same functions as before. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/98ab839f-9100-44ae-9551-9af743a4aa3a@gmail.com
2024-10-29wifi: rtw88: Allow rtw_chip_info.ltecoex_addr to be NULLBitterblue Smith
RTL8821A doesn't have this. Trying to use it results in error messages, so don't try if ltecoex_addr is NULL. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/d1004817-1760-41d1-9136-3d799757c444@gmail.com
2024-10-29wifi: rtw88: Extend the init table parsing for RTL8812AUBitterblue Smith
The chips supported so far only use the first condition, and so the parsing code ignores the second condition. RTL8812AU's init tables use the second condition also. Make the parsing code check it. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/1bee6b74-6eab-44a3-9f40-794ca006c72d@gmail.com
2024-10-29wifi: rtw88: Allow different C2H RA report sizesBitterblue Smith
The RTL8821AU and RTL8812AU have smaller RA report size, only 4 bytes. Avoid the "invalid ra report c2h length" error. Also, use a struct and u8_get_bits() to access the RA report C2H. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c3e73c3a-fb2f-4013-9f06-d5274211e282@gmail.com
generated by cgit (git 2.34.1) at 2025-09-17 05:40:14 +0000