summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2025-04-09wifi: rtw88: Don't set SUPPORTS_AMSDU_IN_AMPDU for RTL8814AUBitterblue Smith
RTL8814AU doesn't work well with SUPPORTS_AMSDU_IN_AMPDU. The RX speed is noticeably lower and the VHT RX statistics are strange. Typical values with SUPPORTS_AMSDU_IN_AMPDU: Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 60710 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 74.6 MBytes 626 Mbits/sec [ 5] 1.00-2.00 sec 79.2 MBytes 665 Mbits/sec [ 5] 2.00-3.00 sec 84.9 MBytes 712 Mbits/sec [ 5] 3.00-4.00 sec 83.8 MBytes 703 Mbits/sec [ 5] 4.00-5.00 sec 85.9 MBytes 720 Mbits/sec [ 5] 5.00-6.00 sec 78.9 MBytes 662 Mbits/sec [ 5] 6.00-7.00 sec 81.2 MBytes 682 Mbits/sec [ 5] 7.00-8.00 sec 80.5 MBytes 675 Mbits/sec [ 5] 8.00-9.00 sec 79.4 MBytes 666 Mbits/sec [ 5] 9.00-10.00 sec 82.2 MBytes 689 Mbits/sec [ 5] 10.00-11.00 sec 82.0 MBytes 688 Mbits/sec [ 5] 11.00-12.00 sec 84.2 MBytes 707 Mbits/sec [ 5] 12.00-13.00 sec 71.0 MBytes 596 Mbits/sec [ 5] 13.00-14.00 sec 69.4 MBytes 582 Mbits/sec [ 5] 14.00-15.00 sec 80.2 MBytes 673 Mbits/sec [ 5] 15.00-16.00 sec 74.5 MBytes 625 Mbits/sec [Rx Counter]: * CCA (CCK, OFDM, Total) = (0, 2455, 2455) * False Alarm (CCK, OFDM, Total) = (0, 69, 69) * CCK cnt (ok, err) = (0, 0) * OFDM cnt (ok, err) = (1239, 2) * HT cnt (ok, err) = (0, 0) * VHT cnt (ok, err) = (21, 12109) The "VHT ok" number is not believable. And without SUPPORTS_AMSDU_IN_AMPDU: Reverse mode, remote host 192.168.0.1 is sending [ 5] local 192.168.0.50 port 50030 connected to 192.168.0.1 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 70.5 MBytes 591 Mbits/sec [ 5] 1.00-2.00 sec 86.9 MBytes 729 Mbits/sec [ 5] 2.00-3.00 sec 98.6 MBytes 827 Mbits/sec [ 5] 3.00-4.00 sec 97.4 MBytes 817 Mbits/sec [ 5] 4.00-5.00 sec 98.6 MBytes 827 Mbits/sec [ 5] 5.00-6.00 sec 96.9 MBytes 813 Mbits/sec [ 5] 6.00-7.00 sec 98.2 MBytes 824 Mbits/sec [ 5] 7.00-8.00 sec 98.0 MBytes 822 Mbits/sec [ 5] 8.00-9.00 sec 99.9 MBytes 838 Mbits/sec [ 5] 9.00-10.00 sec 99.2 MBytes 833 Mbits/sec [ 5] 10.00-11.00 sec 98.0 MBytes 822 Mbits/sec [ 5] 11.00-12.00 sec 98.1 MBytes 823 Mbits/sec [ 5] 12.00-13.00 sec 97.0 MBytes 814 Mbits/sec [ 5] 13.00-14.00 sec 98.2 MBytes 824 Mbits/sec [ 5] 14.00-15.00 sec 98.5 MBytes 826 Mbits/sec [ 5] 15.00-16.00 sec 97.4 MBytes 817 Mbits/sec [Rx Counter]: * CCA (CCK, OFDM, Total) = (0, 3860, 3860) * False Alarm (CCK, OFDM, Total) = (0, 2, 2) * CCK cnt (ok, err) = (0, 0) * OFDM cnt (ok, err) = (1486, 0) * HT cnt (ok, err) = (0, 0) * VHT cnt (ok, err) = (7399, 9118) Add a new member "amsdu_in_ampdu" in struct rtw_chip_info and use it to set SUPPORTS_AMSDU_IN_AMPDU only for the other chips. 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/6202ccfb-feb0-4107-a08d-db2699e179f0@gmail.com
2025-04-09wifi: rtw88: Set AMPDU factor to hardware for RTL8814ABitterblue Smith
Tell the chip the maximum AMPDU size supported by the AP. This greatly improves the TX speed of RTL8814AU in the 2.4 GHz band. Before: ~90 Mbps. After: ~300 Mbps. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/4edc2a63-81b3-431c-9a37-5a7d899a6cc2@gmail.com
2025-04-09wifi: rtw88: usb: Enable RX aggregation for RTL8814AUBitterblue Smith
Let the chip transfer several frames in a single USB Request Block. This is supposed to improve the RX speed. It can use the same code used for RTL8822CU, RTL8822BU, and RTL8821CU. 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/672397ac-dd4d-4420-8b3e-7011578e2243@gmail.com
2025-04-09wifi: rtw88: usb: Enable switching the RTL8814AU to USB 3Bitterblue Smith
The Realtek wifi 5 devices which support USB 3 are weird: when first plugged in, they pretend to be USB 2. The driver needs to send some commands to the device, which make it disappear and come back as a USB 3 device. The method used to switch the RTL8812AU also works for the RTL8814AU. 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/d3608f70-e04f-4f6b-987a-022c8e317165@gmail.com
2025-04-07wifi: ath12k: Fix misspelling "upto" in dp.cJeff Johnson
ath12k-check is flagging: drivers/net/wireless/ath/ath12k/dp.c:1656: 'upto' may be misspelled - perhaps 'up to'? Replace "upto" with "up to" and split the comment line so that it doesn't exceed 80 columns. Link: https://patch.msgid.link/20250407-upto-v1-1-23ca65f2ccdf@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-07wifi: ath12k: Fix invalid memory access while forming 802.11 headerP Praneesh
While forming the 802.11 header from the rx descriptor, skb_push() is performed for the 802.11 header length and then calls ath12k_dp_rx_desc_get_dot11_hdr(). Since skb_push() moves the skb->data pointer backwards by the 802.11 header length, the rx descriptor points to a different memory area than intended, causing invalid information to be fetched from the rx descriptor. Also, when IV and ICV are not stripped from the given MSDU, mac80211 performs PN validation for these MSDUs, which requires the crypto header. Before forming the crypto header from the given rx descriptor, skb_push() is performed for the crypto header length, which overwrites the memory pointed to by the rx descriptor, causing invalid information to form the 802.11 header. Fix these issues by moving all rx descriptor accesses before the skb_push() operation which ensures the proper 802.11 headers are generated from the given rx descriptor and removing ath12k_dp_rxdesc_get_mpdu_frame_ctrl() for filling frame control, as this information is already fetched by ath12k_dp_rx_desc_get_dot11_hdr(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Co-developed-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com> Signed-off-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com> Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Link: https://patch.msgid.link/20250402180543.2670947-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-07wifi: ath12k: Fix memory corruption during MLO multicast txP Praneesh
The struct sk_buff's control buffer is shared by mac80211's struct ieee80211_tx_info and ath12k's struct ath12k_skb_cb. When the driver wants to transmit an skb, it caches all the mac80211-specific information from struct ieee80211_tx_info, then performs a memset on the control buffer before writing the ath12k-specific information using struct ath12k_skb_cb. However, during multicast tx, the key is being filled into the driver data, which overwrites some crucial members like link_id and flags in struct ath12k_skb_cb. This causes invalid information retrieval when the driver accesses these fields during ath12k_dp_tx(). Fix this issue by removing the key filling logic during MLO multicast tx, as it is not used anywhere in the tx path. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 2f50de725677 ("wifi: ath12k: Add support for MLO Multicast handling in driver") Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Link: https://patch.msgid.link/20250402175714.2667270-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-07wifi: ath12k: Fix memory leak during vdev_id mismatchP Praneesh
Currently driver enables vdev_id check as part of the bank configuration in ath12k_dp_tx_get_vdev_bank_config(). This check ensures that the vdev_id configured in the bank register aligns with the vdev_id in the packet's address search table within the firmware. If there is a mismatch, the firmware forwards the packet with the HTT status HAL_WBM_REL_HTT_TX_COMP_STATUS_VDEVID_MISMATCH. Since driver does not handle this vdev_id mismatch HTT status, the corresponding buffers are not freed properly, causing a memory leak. Fix this issue by adding handling to free the buffers when a vdev_id mismatch HTT status is encountered. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ- Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Link: https://patch.msgid.link/20250402174032.2651221-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-07wifi: ath12k: Fix incorrect rates sent to firmwarePradeep Kumar Chitrapu
Before firmware assert, if there is a station interface in the device which is not associated with an AP, the basic rates are set to zero. Following this, during firmware recovery, when basic rates are zero, ath12k driver is sending invalid rate codes, which are negative values, to firmware. This results in firmware assert. Fix this by checking if rate codes are valid, before sending them to the firmware. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> Signed-off-by: Roopni Devanathan <quic_rdevanat@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250320112426.1956961-1-quic_rdevanat@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-05treewide: Switch/rename to timer_delete[_sync]()Thomas Gleixner
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree over and remove the historical wrapper inlines. Conversion was done with coccinelle plus manual fixups where necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-04-03wifi: ath12k: Enable REO queue lookup table feature on QCN9274Nithyanantham Paramasivam
Enable the REO queue lookup table feature for QCN9274 by setting the reoq_lut_support flag. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Nithyanantham Paramasivam <quic_nithp@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250402152529.1649402-4-quic_nithp@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-03wifi: ath12k: Add support to clear qdesc array in REO cacheBalamurugan S
Currently, the existing code lacks functionality to clear the qdesc array in the REO cache. As a result, any updates in the LUT are not reflected in the REO cache. To address this issue, add functionality to clear the qdesc array in the REO cache during a peer TID update. To do this, set the CLEAR_DESC_ARRAY field of WCSS_UMAC_REO_R0_QDESC_ADDR_READ and then reset it. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Balamurugan S <quic_bselvara@quicinc.com> Signed-off-by: Nithyanantham Paramasivam <quic_nithp@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250402152529.1649402-3-quic_nithp@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-03wifi: ath12k: Fix the enabling of REO queue lookup table featureSriram R
Instead of storing the REO queue address inside peer entries, REO hardware module prefers them to be stored in SRAM which could be directly accessed by REO using peer_ID/TID based lookup table mechanism. Fix the enabling of the REO queue lookup table(LUT) feature by configuring the LUT address information in the REO hardware register and setting the host service flags. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Signed-off-by: Nithyanantham Paramasivam <quic_nithp@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250402152529.1649402-2-quic_nithp@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: ath11k: fix node corruption in ar->arvifs listStone Zhang
In current WLAN recovery code flow, ath11k_core_halt() only reinitializes the "arvifs" list head. This will cause the list node immediately following the list head to become an invalid list node. Because the prev of that node still points to the list head "arvifs", but the next of the list head "arvifs" no longer points to that list node. When a WLAN recovery occurs during the execution of a vif removal, and it happens before the spin_lock_bh(&ar->data_lock) in ath11k_mac_op_remove_interface(), list_del() will detect the previously mentioned situation, thereby triggering a kernel panic. The fix is to remove and reinitialize all vif list nodes from the list head "arvifs" during WLAN halt. The reinitialization is to make the list nodes valid, ensuring that the list_del() in ath11k_mac_op_remove_interface() can execute normally. Call trace: __list_del_entry_valid_or_report+0xb8/0xd0 ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k] drv_remove_interface+0x48/0x194 [mac80211] ieee80211_do_stop+0x6e0/0x844 [mac80211] ieee80211_stop+0x44/0x17c [mac80211] __dev_close_many+0xac/0x150 __dev_change_flags+0x194/0x234 dev_change_flags+0x24/0x6c devinet_ioctl+0x3a0/0x670 inet_ioctl+0x200/0x248 sock_do_ioctl+0x60/0x118 sock_ioctl+0x274/0x35c __arm64_sys_ioctl+0xac/0xf0 invoke_syscall+0x48/0x114 ... Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Stone Zhang <quic_stonez@quicinc.com> Link: https://patch.msgid.link/20250320053145.3445187-1-quic_stonez@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: ath12k: Fix spelling errors in mac.c fileMaharaja Kennadyrajan
Fix spelling error correpsondig -> corresponding in the comments within the file mac.c Compile tested only. Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250401173755.1982382-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: ath12k: store and send country code to firmware after recoveryWen Gong
Currently ath12k does not send the country code to firmware after device recovery. As a result the country code will be the default one which is reported from firmware. Country code is important, so ath12k also need to restore it to the value which was used before recovery. This is only needed for platforms which support the current_cc_support hardware parameter. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kang Yang <quic_kangyang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250401020840.357-5-quic_kangyang@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: ath12k: add 11d scan offload supportWen Gong
The flow of 11d scan is: 1. trigger 11d scan. 2. receive, parse, and update 11d scan result. 3. stop 11d scan. So need to add handler for WMI_11D_SCAN_START_CMDID and WMI_11D_SCAN_STOP_CMDID to trigger/stop 11d scan. Add process of WMI event WMI_11D_NEW_COUNTRY_EVENTID for 11d scan result. There are two points that need to be noted: 1. The 11d scan priority is 'MEDIUM' in firmware, the hw scan priority is 'LOW'. When 11d scan is running, hw scan will be canceled. To avoid this, change the hw scan priority to 'MEDIUM' when 11d scan is running. 2. Need to add wait_for_completion_timeout() for scan.complete in ath12k_reg_update_chan_list() because 11d scan will cost more than 5 seconds. Due to another existing wait in ath12k_scan_stop(), there will be two scan.complete in different threads. Therefore use complete_all() instead of complete() for scan.complete. complete_all() can work well when it is only one thread wait for scan.complete. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kang Yang <quic_kangyang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250401020840.357-4-quic_kangyang@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: ath12k: use correct WMI command to set country code for WCN7850Wen Gong
When userspace tries to set country code by NL80211_REGDOM_SET_BY_USER hint(like iw reg set XX), it will pass new country code to ath12k. Then ath12k will set this new country code to firmware by WMI_SET_INIT_COUNTRY_CMDID. For AP based chips(QCN92xx), WMI_SET_INIT_COUNTRY_CMDID is the correct command. However, for STATION based chips(WCN7850), it need to use WMI_SET_CURRENT_COUNTRY_CMDID. Add flag current_cc_support in hardware parameters. It is used to distinguish AP/STA platform. After that, the firmware will work normally and the regulatory feature works well for WCN7850. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kang Yang <quic_kangyang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250401020840.357-3-quic_kangyang@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: ath12k: add configure country code for WCN7850Wen Gong
Currently, WMI_SET_INIT_COUNTRY_CMDID is used to set country code for WCN7850 and QCN9274. But WMI_SET_INIT_COUNTRY_CMDID is not the correct command for WCN7850. Add handler to send WMI_SET_CURRENT_COUNTRY_CMDID to firmware, which is used for WCN7850 to update country code. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Kang Yang <quic_kangyang@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250401020840.357-2-quic_kangyang@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: ath12k: Fix memory leak due to multiple rx_stats allocationSidhanta Sahu
rx_stats for each arsta is allocated when adding a station. arsta->rx_stats will be freed when a station is removed. Redundant allocations are occurring when the same station is added multiple times. This causes ath12k_mac_station_add() to be called multiple times, and rx_stats is allocated each time. As a result there is memory leaks. Prevent multiple allocations of rx_stats when ath12k_mac_station_add() is called repeatedly by checking if rx_stats is already allocated before allocating again. Allocate arsta->rx_stats if arsta->rx_stats is NULL respectively. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: Sidhanta Sahu <sidhanta.sahu@oss.qualcomm.com> Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com> Reviewed-by: Mahendran P <quic_mahep@quicinc.com> Link: https://patch.msgid.link/20250326213538.2214194-1-muna.sinada@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-02wifi: wl1251: fix memory leak in wl1251_tx_workAbdun Nihaal
The skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup fails with a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue. Fixes: c5483b719363 ("wl12xx: check if elp wakeup failed") Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com> Reviewed-by: Michael Nemanov <michael.nemanov@ti.com> Link: https://patch.msgid.link/20250330104532.44935-1-abdun.nihaal@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-02wifi: brcmfmac: fix memory leak in brcmf_get_module_paramAbdun Nihaal
The memory allocated for settings is not freed when brcmf_of_probe fails. Fix that by freeing settings before returning in error path. Fixes: 0ff0843310b7 ("wifi: brcmfmac: Add optional lpo clock enable support") Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250330103425.44197-1-abdun.nihaal@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-02wifi: iwlwifi: mld: silence uninitialized variable warningDan Carpenter
The "resp_len" isn't initialized if iwl_dhc_resp_data() fails. Fixes: b611cf6b57a8 ("wifi: iwlwifi: mld: add support for DHC_TOOLS_UMAC_GET_TAS_STATUS command") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/add9c9e2-3b44-4e0a-a4aa-7326f6425baf@stanley.mountain [fix typo in commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-02wifi: at76c50x: fix use after free access in at76_disconnectAbdun Nihaal
The memory pointed to by priv is freed at the end of at76_delete_device function (using ieee80211_free_hw). But the code then accesses the udev field of the freed object to put the USB device. This may also lead to a memory leak of the usb device. Fix this by using udev from interface. Fixes: 29e20aa6c6af ("at76c50x-usb: fix use after free on failure path in at76_probe()") Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com> Link: https://patch.msgid.link/20250330103110.44080-1-abdun.nihaal@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-02iwlwifi: mld: fix building with CONFIG_PM_SLEEP disabledArnd Bergmann
The newly added driver causes multiple build problems when CONFIG_PM_SLEEP is disabled: drivers/net/wireless/intel/iwlwifi/mld/mac80211.c:1982:12: error: 'iwl_mld_resume' defined but not used [-Werror=unused-function] 1982 | static int iwl_mld_resume(struct ieee80211_hw *hw) | ^~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/mld/mac80211.c:1960:1: error: 'iwl_mld_suspend' defined but not used [-Werror=unused-function] 1960 | iwl_mld_suspend(struct ieee80211_hw *hw, struct cfg80211_wowlan *wowlan) | ^~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/mld/mac80211.c:1946:13: error: 'iwl_mld_set_wakeup' defined but not used [-Werror=unused-function] 1946 | static void iwl_mld_set_wakeup(struct ieee80211_hw *hw, bool enabled) | ^~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/mld/mac80211.c: In function 'iwl_mld_mac80211_start': drivers/net/wireless/intel/iwlwifi/mld/mac80211.c:504:20: error: 'ret' is used uninitialized [-Werror=uninitialized] 504 | if (!in_d3 || ret) { | ^~ drivers/net/wireless/intel/iwlwifi/mld/mac80211.c:478:13: note: 'ret' was declared here 478 | int ret; | ^~~ Hide the unused functions and make sure the 'ret' variable is not used before the initialization. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20250325084340.378724-1-arnd@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-02wifi: iwlwifi: mld: fix PM_SLEEP -Wundef warningJohannes Berg
Config symbols are not defined if turned off, so need to use #ifdef, not #if. Fixes: d1e879ec600f9 ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Yedidya Ben Shimol <yedidya.ben.shimol@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250401064530.612020bcdaad.I4e885e6646576e29fb236250a1b5038d3f14b08e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-02wifi: iwlwifi: mld: reduce scope for uninitialized variableYedidya Benshimol
After resuming from D3, keeping the connection or disconnecting isn't relevant for the case of netdetect. Reduce the scope of the keep_connection indicator to wowlan only. Fixes: d1e879ec600f9 ("wifi: iwlwifi: add iwlmld sub-driver") Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250401064530.769f76a9ad6e.I69e8f194997eb3a20e40d27fdc31002d5753d905@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-31Reapply "wifi: ath11k: restore country code during resume"Baochen Qiang
This reverts commit d3e154d7776ba57ab679fb816fb87b627fba21c9. With non-WoWLAN suspend support brought back, commit 7f0343b7b871 ("wifi: ath11k: restore country code during resume") needs to be brought back as well. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-6-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-03-31wifi: ath11k: choose default PM policy for hibernationBaochen Qiang
Now WoWLAN mode is chosen for those machines listed in the quirk table. This works for suspend (S3) but breaks for hibernation (S4), because WoWLAN mode requires WLAN power to be sustained, which is not the case during hibernation. For hibernation, the default mode should be used. Register a PM notifier with which kernel can notify us of the actual PM operation: if system is going to suspend, the original PM policy is honored; while if it is hibernation, overwrite it with default policy. To summarize: for suspend (S3), WoWLAN mode is chosen for machines listed in the quirk table, non-WoWLAN mode for others; for hibernation (S4), non-WoWLAN mode is chosen for all. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-5-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-03-31wifi: ath11k: support non-WoWLAN mode suspend as wellBaochen Qiang
Previously commit 166a490f59ac ("wifi: ath11k: support hibernation") was reverted due to [1], so currently we only support WoWLAN mode suspend. This works well in scenarios where WLAN power is sustained during suspend, however breaks in those where power is cut off. This change basically brings the reverted commit back, but differs in that we decide based on the PM policy to choose WoWLAN mode suspend or the non-WoWLAN mode. As stated in the previous patch for now the PM policy is determined based on machine models. That said we will choose WoWLAN mode suspend if we are running on machines listed in ath11k_pm_quirk_table, otherwise we choose the other one. [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-4-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-03-31wifi: ath11k: refactor ath11k_core_suspend/_resume()Baochen Qiang
Due to [1] we currently put WLAN target into WoWLAN mode regardless of machine models. In upcoming patches we will support another mode, and finally which mode is chosen depends on the exact machine model. To prepare for such change, refactor the actual WoWLAN stuff in ath11k_core_suspend() into a new helper ath11k_core_suspend_wow(), this increase the code readability when the new suspend mode is added in upcoming patches. Same change applies to ath11k_core_resume(); [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-3-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-03-31wifi: ath11k: introduce ath11k_core_continue_suspend_resume()Baochen Qiang
Currently ath11k_core_suspend() and ath11k_core_resume() have the same check before going on. In upcoming patches the check is needed by some newly added functions as well. To avoid duplicate code, introduce a new helper ath11k_core_continue_suspend_resume() which does such check internally. Callers can decide whether to go on based on its return value. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-2-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-03-31wifi: ath11k: determine PM policy based on machine modelBaochen Qiang
To handle the Lenovo unexpected wakeup issue [1], previously we revert commit 166a490f59ac ("wifi: ath11k: support hibernation"). So currently WLAN target is put into WoWLAN mode during suspend. This is a temporary solution as it does not work on machines where WLAN power is cut off. The thought here is that we do WoWLAN suspend on Lenovo machines while do non-WoWLAN suspend (which is done in the reverted commit) on other machines. This requires us to identify Lenovo machines from others. For that purpose, read board vendor and product name from DMI interface, match it against all known affected machines. If there is a match, choose WoWLAN suspend mode, else choose non-WoWLAN mode. Save the mode in ab for later reference. [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250328-ath11k-bring-hibernation-back-v3-1-23405ae23431@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-03-31wifi: rtw88: usb: Remove redundant 'flush_workqueue()' callsChen Ni
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250324080303.408084-1-nichen@iscas.ac.cn
2025-03-31wifi: rtw88: sdio: Remove redundant 'flush_workqueue()' callsChen Ni
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250324075910.407999-1-nichen@iscas.ac.cn
2025-03-31wifi: rtw89: 8852bx: support different SAR configs by antennaZong-Zhe Yang
Calculate difference of SAR configs between RF path A and RF path B. And then, based on the calculated result, set the TX power reference CR (control register). Finally, declare to support SAR by antenna in 8852b/8852bt chip info. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-13-pkshih@realtek.com
2025-03-31wifi: rtw89: 8852c: support different SAR configs by antennaZong-Zhe Yang
Set SAR configs to the corresponding CRs (control registers) according to RF path. Then, declare to support SAR by antenna in chip info. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-12-pkshih@realtek.com
2025-03-31wifi: rtw89: 8922a: support different SAR configs by antennaZong-Zhe Yang
Set SAR configs to the corresponding CRs (control registers) according to RF path. Then, declare to support SAR by antenna in chip info. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-11-pkshih@realtek.com
2025-03-31wifi: rtw89: sar: add skeleton for different configs by antennaZong-Zhe Yang
Some SAR sources, e.g. ACPI, may allow different SAR configs by antenna. Previously, the minimum config between antennas was taken. Because there are differences between HW design, different chips might have different solutions to achieve this. So, it cannot be done through a single common handling. Now, add the relevant skeleton for this purpose ahead. First, add a flag into chip info to describe whether it has implemented this function or not. Second, support to query SAR config for a given RF path. With it, each chip can implement its own handling. Then, if a chip declares to support this function, when it queries SAR config without a given RF path, it gets a maximum config between antennas. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-10-pkshih@realtek.com
2025-03-31wifi: rtw89: acpi: support loading GEO SAR tablesZong-Zhe Yang
Support to load GEO (geography) SAR tables with ACPI RWGS method. When SAR values could be different by regulatory, GEO SAR can be used. The format of GEO SAR is like the following, where regulatory number, band number, and delta number are determined by header of either static SAR or dynamic SAR. (It also means that no GEO SAR will be considered when neither static SAR nor dynamic SAR is configured.) delta number / \ + +-----+-----------------+ / | | max | delta... | \ / | +-----+-----------------+ band / | | max | delta... | number / | +-----+-----------------+ / | |... | / + +-----+-----------------+ | | max | delta... | \ regulatory | +-----+-----------------+ band number | | max | delta... | number | +-----+-----------------+ | |... | / + +-----+-----------------+ \ | |... | \ | |... | \ | |... | \ | | | \ | | | + +-----+-----------------+ Each entry of GEO SAR contains delta field(s), which are offset(s) used to tweak the loaded static/dynamic SAR table(s) by antenna, and one max field, which describes the maximum of the final SAR values after tweaked. Different entries should be configured based on both regulatory and band. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-9-pkshih@realtek.com
2025-03-31wifi: rtw89: acpi: support loading dynamic SAR tables and indicatorZong-Zhe Yang
Support to load dynamic SAR tables with ACPI RWRD method. The content format of a single dynamic SAR table is basically the same as static SAR table. However, it's able to carry multiple dynamic SAR tables at one time. And, its header contains one more field to describe how many dynamic SAR tables are filled in the content. Either static SAR table or dynamic SAR tables can be supported, but not both simultaneously. Besides, also support to load indicator of dynamic SAR with ACPI RWSI method. The indicator will describe a target dynamic SAR table, which should be followed currently, by antenna. It can be changed at runtime according to platform mode. For example, tablet mode can use different SAR from normal mode. So, track indicator configuration if dynamic SAR is configured. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-8-pkshih@realtek.com
2025-03-31wifi: rtw89: acpi: support loading static SAR tableZong-Zhe Yang
Support to load static SAR table with ACPI WRDS method. The format of a static SAR table is like the following, where according to header, antenna number could be either 2 or 4 and subband number could either contain 6 GHz or not. And then, an entry of it describes a TX power limitation with a given unit, which is also based on header, for the antenna under the subband. Though things can be determined by header, still not all combinations are allowed in content. For the recognizing flow, there is a list of allowed combinations. +--------------------------------+ | header | +--------------------------------+ +---+---+---+---+---+------------+ + / | | | | | | ... | | \ +---+---+---+---+---+------------+ | antenna | | | | | | ... | | number +---+---+---+---+---+------------+ | content |...| | | | | ... | | +---+---+---+---+---+------------+ | \ |...| | | | | ... | | / +---+---+---+---+---+------------+ + \ / subband number Following the format above, try to load a static SAR table and normalize its content into SW structure. If any recognized is loaded, SW SAR flow is then set up with source from ACPI. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-7-pkshih@realtek.com
2025-03-31wifi: rtw89: acpi: introduce method evaluation function for reuseZong-Zhe Yang
The following implementations will evaluate different ACPI methods, but the pre-process flow of them are the same. So, introduce a function for these pre-process things. Besides, also change ACPI RTAG method to call this function. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-6-pkshih@realtek.com
2025-03-31wifi: rtw89: sar: add skeleton for SAR configuration via ACPIZong-Zhe Yang
To support SAR configuration in BIOS via ACPI, add related subbnad/band converting/handling function and define SW format to store result after parsing. Then, register a new SAR source, i.e. ACPI, into SAR flow and implement its query function. Besides, tweak priority of common SAR to be the highest. And, ACPI SAR can just be configured once when no other sources is already working. For now, evaluating SAR via ACPI returns -ENOENT, i.e. ACPI SAR doesn't really work yet. The evaluating flow will be implemented 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/20250326020643.14487-5-pkshih@realtek.com
2025-03-31wifi: rtw89: sar: introduce structure to wrap query parametersZong-Zhe Yang
The following implementations will support SAR source from ACPI/BIOS. And when querying, it needs to take more parameters into account. To avoid changing function prototype of querying SAR everytime when new SAR source is introduced, wrap query parameters into a structure first. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-4-pkshih@realtek.com
2025-03-31wifi: rtw89: regd: introduce string getter for reuseZong-Zhe Yang
Introduce a function to get the string for a given regulatory. It will be used in the following. Besides, drop similar things in debug code and use this too. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250326020643.14487-3-pkshih@realtek.com
2025-03-31wifi: rtw89: fix typo of "access" in rtw89_sar_info descriptionZong-Zhe Yang
The "acces" should be "access". So, fix 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/20250326020643.14487-2-pkshih@realtek.com
2025-03-31wifi: rtw89: phy: reset value of force TX power for MAC IDPing-Ke Shih
The force TX power function is disabled, but the force TX power value is preserved, causing misunderstand the behavior in debug. Clear all values. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250325031021.15619-1-pkshih@realtek.com
2025-03-31wifi: rtw89: fw: cast mfw_hdr pointer from address of zeroth byte of ↵Ping-Ke Shih
firmware->data The firmware->size is validated before using firmware->data, but Coverity still reports: Downcasting "firmware->data" from "u8 const *" to "struct rtw89_mfw_hdr" implies that the data that this pointer points to is tainted." Using &firmware->data[0] to avoid the warning. No change logic at all. Addresses-Coverity-ID: 1494046 ("Untrusted loop bound") Addresses-Coverity-ID: 1544385 ("Untrusted array index read") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250325025424.14079-1-pkshih@realtek.com
2025-03-31wifi: rtw89: set 2TX for 1SS rate by defaultPing-Ke Shih
To improve performance in range, for 1SS rate, transmit the same signal on 2 antenna, which is called 2TX. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250321034736.6269-1-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-07-18 20:10:18 +0000