summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
2025-04-17wifi: ath12k: Avoid allocating rx_stats when ext_rx_stats is disabledP Praneesh
Currently, driver allocates the struct ath12k_rx_peer_stats for each station regardless of whether ext_rx_stats is enabled. This structure is populated by the monitor destination ring for both single-user and multi-user scenarios when ext_rx_stats is enabled. However, when ext_rx_stats is disabled, this allocation is unnecessary and results in additional memory consumption. To address this issue, allocate the struct ath12k_rx_peer_stats only when ext_rx_stats is enabled through debugfs. This change prevents unnecessary memory allocation. Additionally, ensure that the station dump RSSI is updated irrespective of the ext_rx_stats enablement. 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: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250409052647.81955-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: avoid deadlock during regulatory update in ath12k_regd_update()Wen Gong
Running this test in a loop it is easy to reproduce an rtnl deadlock: iw reg set FI ifconfig wlan0 down What happens is that thread A (workqueue) tries to update the regulatory: try to acquire the rtnl_lock of ar->regd_update_work rtnl_lock ath12k_regd_update [ath12k] ath12k_regd_update_work [ath12k] process_one_work worker_thread kthread ret_from_fork And thread B (ifconfig) tries to stop the interface: try to cancel_work_sync(&ar->regd_update_work) in ath12k_mac_op_stop(). ifconfig 3109 [003] 2414.232506: probe: ath12k_mac_op_stop [ath12k] drv_stop [mac80211] ieee80211_do_stop [mac80211] ieee80211_stop [mac80211] The sequence of deadlock is: 1. Thread B calls rtnl_lock(). 2. Thread A starts to run and calls rtnl_lock() from within ath12k_regd_update_work(), then enters wait state because the lock is owned by thread B. 3. Thread B tries to call cancel_work_sync(&ar->regd_update_work), but thread A is in ath12k_regd_update_work() waiting for rtnl_lock(). So cancel_work_sync() forever waits for ath12k_regd_update_work() to finish and we have a deadlock. Change to use regulatory_set_wiphy_regd(), which is the asynchronous version of regulatory_set_wiphy_regd_sync(). This way rtnl & wiphy locks are not required so can be removed, and in the end the deadlock issue can be avoided. But a side effect introduced by the asynchronous regd update is that, some essential information used in ath12k_reg_update_chan_list(), which would be called later in ath12k_regd_update(), might has not been updated by cfg80211, as a result wrong channel parameters sent to firmware. To handle this side effect, move ath12k_reg_update_chan_list() to ath12k_reg_notifier(), and advertise WIPHY_FLAG_NOTIFY_REGDOM_BY_DRIVER to cfg80211. This works because, in the process of the asynchronous regd update, after the new regd is processed, cfg80211 will notify ath12k by calling ath12k_reg_notifier(). Since all essential information is updated at that time, we are good to do channel list update. Please note ath12k_reg_notifier() could also be called due to other reasons, like core/beacon/user hints etc. For them we are not allowed to call ath12k_reg_update_chan_list() because regd has not been updated. This is done by verifying the initiator. 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> Co-developed-by: Baochen Qiang <quic_bqiang@quicinc.com> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-rtnl-deadlock-v3-1-fdc12bc511ea@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Add MSDU length validation for TKIP MIC errorP Praneesh
In the WBM error path, while processing TKIP MIC errors, MSDU length is fetched from the hal_rx_desc's msdu_end. This MSDU length is directly passed to skb_put() without validation. In stress test scenarios, the WBM error ring may receive invalid descriptors, which could lead to an invalid MSDU length. To fix this, add a check to drop the skb when the calculated MSDU length is greater than the skb size. 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 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: P Praneesh <quic_ppranees@quicinc.com> Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250416021903.3178962-1-nithyanantham.paramasivam@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: fix invalid access to memorySarika Sharma
In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean is_continuation is part of rxcb. Currently, after freeing the skb, the rxcb->is_continuation accessed again which is wrong since the memory is already freed. This might lead use-after-free error. Hence, fix by locally defining bool is_continuation from rxcb, so that after freeing skb, is_continuation can be used. Compile tested only. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408045327.1632222-1-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: correctly handle mcast packets for clientsSarika Sharma
Currently, RX is_mcbc bit is set for packets sent from client as destination address (DA) is multicast/broadcast address, but packets are actually unicast as receiver address (RA) is not multicast address. Hence, packets are not handled properly due to this is_mcbc bit. Therefore, reset the is_mcbc bit if interface type is AP. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411061523.859387-3-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: using msdu end descriptor to check for rx multicast packetsSarika Sharma
Currently, the RX multicast broadcast packet check is performed using bit 15 from the info6 field of the MPDU start descriptor. This check can also be done using bit 9 from the info5 field of the MSDU end descriptor. However, in some scenarios multicast bit is not set when fetched from MPDU start descriptor. Therefore, checking the RX multicast broadcast packet from the MSDU end descriptor is more reliable as it is per MSDU. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sarika Sharma <quic_sarishar@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411061523.859387-2-quic_sarishar@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Update frequency range if reg rules changesAditya Kumar Singh
During the hardware register, driver updates the frequency range during boot-up. However, if new regulatory rules are applied after boot-up, the frequency range remains based on the older rules. Since different countries have varying regulatory rules, the frequency range can differ. Retaining the frequency range based on outdated rules can be misleading. Update the frequency range according to the new regulatory rules in the function ath12k_regd_update(). 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Co-developed-by: Rajat Soni <quic_rajson@quicinc.com> Signed-off-by: Rajat Soni <quic_rajson@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408042128.720263-4-quic_rajson@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Fix frequency range in driverAditya Kumar Singh
During the initial WMI exchange, the firmware updates the hardware-supported start and end frequencies in the ath12k_wmi_hal_reg_capabilities_ext_arg structure. These frequencies, being hardware-supported, may not always align with the current regulatory operating frequencies. When operating as multiple grouped hardwares under a single wiphy, the driver advertises these values directly to the upper layer in the per-radio frequency range, which can be misleading. Sample output snippet from iw phyX info command - [..] Supported wiphy radios: * Idx 0: Frequency Range: 2312 MHz - 2732 MHz [..] * Idx 1: Frequency Range: 5150 MHz - 5330 MHz [..] [..] The frequency range displayed above is incorrect because the driver directly advertises the hardware-supported values to the upper layer. The driver is aware of the current operating regulatory rules, and hence it can use this information to determine the final operating start and end frequencies. To resolve this issue, add support to store the start and end frequencies received during the regulatory update event. Then, intersect these with the hardware-supported start and end frequencies, and finally, advertise the intersected values to the upper layer. Sample output snippet from iw phyX info command after the fix - [..] Supported wiphy radios: * Idx 0: Frequency Range: 2402 MHz - 2472 MHz [..] * Idx 1: Frequency Range: 5170 MHz - 5330 MHz [..] [..] 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Co-developed-by: Rajat Soni <quic_rajson@quicinc.com> Signed-off-by: Rajat Soni <quic_rajson@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408042128.720263-3-quic_rajson@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Add helper function ath12k_mac_update_freq_range()Rajat Soni
In a subsequent change, the frequency range needs to be updated with each regulatory update. Since the current function also modifies the DISABLED flag in the actual channel list, which should always align with hardware-supported start and end frequencies rather than the current operating ones, the existing function cannot be called again. Therefore, the logic for setting the frequency range needs to be refactored. To address this, refactor the frequency setting part into a new helper function, ath12k_mac_update_freq_range(). Since this needs to be done independently of updating the DISABLED flag, call the new helper function ath12k_mac_update_freq_range() after updating the channel list for each band. 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 Signed-off-by: Rajat Soni <quic_rajson@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408042128.720263-2-quic_rajson@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Use skb->len for dma_unmap_single() length parameterP Praneesh
During dma_unmap_single() for extended skb, the driver currently uses sizeof() of the corresponding structure. When the allocation size changes, one of the parameters of dma_unmap_single() needs to be updated everywhere. Improve code readability by using skb->len instead of sizeof() the structure. 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 Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-5-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Fix memory leak during extended skb allocationP Praneesh
In ath12k_dp_tx(), memory allocated for extended skb is not freed properly, causing a memory leak even when the host receives tx completion for those skbs. Fix this issue by storing skb_ext_desc in the host tx descriptor and using this skb_ext_desc field during completion or during ath12k_dp_cc_cleanup(). 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") Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-4-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Refactor tx descriptor handling in tx completion handlerP Praneesh
Current code uses mac_id and msdu parameters in ath12k_dp_tx_free_txbuf() and ath12k_dp_tx_process_htt_tx_complete(). Since these parameters are already encapsulated by struct ath12k_dp_tx_desc, passing them individually results in redundant arguments. Introduce struct ath12k_tx_desc_params to capture the skb, mac_id, and pass it to the corresponding functions. Refactor these functions to use struct ath12k_tx_desc_params instead, reducing the number of arguments and improving function argument handling efficiency. Additionally, use struct ath12k_tx_desc_params in ath12k_dp_tx_htt_tx_complete_buf() and ath12k_dp_tx_complete_msdu(), which will be utilized for fetching extended skb in a future patch. 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 Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-3-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: ath12k: Handle error cases during extended skb allocationP Praneesh
Currently, in the case of extended skb allocation, the buffer is freed before the DMA unmap operation. This premature deletion can result in skb->data corruption, as the memory region could be re-allocated for other purposes. Fix this issue by reordering the failure cases by calling dma_unmap_single() first, then followed by the corresponding kfree_skb(). This helps avoid data corruption in case of failures in dp_tx(). 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") Signed-off-by: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250411060154.1388159-2-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-17wifi: rtw88: do not ignore hardware read error during DPKDmitry Antipov
In 'rtw8822c_dpk_cal_coef1()', do not ignore error returned by 'check_hw_ready()' but issue a warning to denote possible DPK issue. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5227c2ee453d ("rtw88: 8822c: add SW DPK support") Suggested-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250415090720.194048-1-dmantipov@yandex.ru
2025-04-17wifi: rtw88: sdio: call rtw_sdio_indicate_tx_status unconditionallyZhen XIN
The rtw88-sdio do not work in AP mode due to the lack of TX status report for management frames. Make the invocation of rtw_sdio_indicate_tx_status unconditional and cover all packet queues Tested-on: rtl8723ds Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250410154217.1849977-2-zhen.xin@nokia-sbell.com
2025-04-17wifi: rtw88: sdio: map mgmt frames to queue TX_DESC_QSEL_MGMTZhen XIN
The rtw88-sdio do not work in AP mode due to the lack of TX status report for management frames. Map the management frames to queue TX_DESC_QSEL_MGMT, which enables the chip to generate TX reports for these frames Tested-on: rtl8723ds Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Signed-off-by: Zhen XIN <zhen.xin@nokia-sbell.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250410154217.1849977-3-zhen.xin@nokia-sbell.com
2025-04-15wifi: ath12k: support 2 channels for single pdev deviceBaochen Qiang
For single pdev device, radio number of a device is forced as 1 in ath12k_wmi_ext_soc_hal_reg_caps_parse(). This leads to ah->num_radio == 1 and then in ath12k_mac_setup_iface_combinations() we report to mac/cfg80211 that only 1 channel is supported. In MLO case, it finally results in failing to bring up the second link as it is in another channel. Change num_different_channels to 2 to allow a second link. Since DFS on multiple channels are not supported yet, remove radar_detect_widths. For now WCN7850 is the only single pdev device, so others should not be affected. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-9-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: don't skip non-primary links for WCN7850Baochen Qiang
The primary link check bypasses REO queue setup for non-primary links in ath12k_dp_rx_peer_tid_setup(), this works for QCN9274 but breaks WCN7850 as WCN7850 needs it to be done for each link peer. Add a new hardware parameter to differentiate them. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-8-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: alloc REO queue per stationBaochen Qiang
In MLO case, all link peers share the same REO queue, so the queue should be allocated only once, currently this is done by checking primary_link flag in ath12k_dp_rx_peer_tid_setup(). However, the check not only avoids duplicate allocation, but also bypasses sending queue configuration to firmware for non-primary links. In an upcoming patch, changes will be added to make this check no-ops for WCN7850, as WCN7850 firmware needs to be explicitly notified each link peer's queue configuration. That said, the duplicate allocation would arise again after that change, hence it needs to be resolved before hand. Since all link peers share the same queue, it should be allocated per MLD peer, not per link peer. So change to do allocation once and save it in MLD peer, link peers can simply get queue configuration from there. Also relocate ath12k_reoq_buf structure to core.h to avoid circular dependency. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-7-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: group REO queue buffer parameters togetherBaochen Qiang
Currently vaddr, paddr and size fields are located together with other fields in ath12k_dp_rx_tid structure. Logically they represents the REO queue buffer so better to group them in an individual structure. Introduce a new structure ath12k_reoq_buf to group them. This improves code readability, and benefits the upcoming patch where this structure is heavily accessed. While at it, change vaddr type to 'void *' since it is actually not pointing to any u32 buffer. Also rename paddr as paddr_aligned to better reflect its actual meaning. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-6-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: make assoc link associate firstBaochen Qiang
In MLO scenario WCN7850 firmware requests the assoc link to associate before any other links. However currently in ath12k_mac_op_vif_cfg_changed() we are doing association in an ascending order of link id. If the assoc link does not get assigned the smallest id, a non-assoc link gets associated first and firmware crashes. Change to do association for the assoc link first. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-5-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: identify assoc link vif in station modeBaochen Qiang
In MLO scenario, for station mode interface, WCN7850 firmware requests the assoc link vdev to get started before any other link vdevs starts. Firmware internally checks assoc_link field of wmi_vdev_start_mlo_params.flags when the first vdev starts. And if the check fails firmware crashes. Current connection flow guarantees the assoc link vdev gets started first (at assoc stage only one link vdev is created/started, i.e. the assoc link vdev), however the assoc_link flag is never set, resulting in WCN7850 firmware crash. Note ath12k_link_sta structure already has is_assoc_link flag, and it is properly set for assoc link. However we can not use it because it won't be available before peer gets created, which is too late for vdev starts. So add a new flag 'is_sta_assoc_link' in ath12k_link_vif structure and set it when deflink vdev is created. This is valid because we always use deflink as the assoc link. This flag is passed to firmware vdev starts to avoid firmware crash. Also verify the link vif/sta pair has the same settings when creating link sta. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-4-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: support MLO as well if single_chip_mlo_support flag is setBaochen Qiang
Currently firmware MLO capability is validated via firmware IE, however WCN7850 firmware does not support this method but instead advertises MLO by single_chip_mlo_support bit in QMI phy capability message. Change to consider single_chip_mlo_support bit as well for MLO capability validation. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-3-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: use fw_features only when it is validBaochen Qiang
Currently fw_features is used to check if a specific feature is supported or not: if the feature bit is set the feature is believed to be supported, otherwise not supported. Since fw_features is populated only when using firmware API-2, and by default it is zero, in case of API-1 such as WCN7850 firmware it is possible that a feature is not enabled by host while actually firmware supports it. To avoid this, add a new flag indicating whether fw_features has been ever populated or not, and only when that flag is true we choose to believe fw_features. This benefits firmware MLO capability validation in an upcoming patch. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-2-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-15wifi: ath12k: introduce ath12k_fw_feature_supported()Baochen Qiang
There are several places checking if a specific bit set in ab->fw.fw_features, and in an upcoming patch additional check needs to be added at all places. Introduce a new helper ath12k_fw_feature_supported() to avoid code duplication. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com> Link: https://patch.msgid.link/20250409-ath12k-wcn7850-mlo-support-v2-1-3801132ca2c3@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: reset MLO global memory during recoveryAditya Kumar Singh
When operating with multiple devices grouped together, the firmware stores data related to the state machine of each partner device in the MLO global memory region. If the firmware crashes, it updates the state to 'crashed'. During recovery, this memory is shared with the firmware again, and upon detecting the 'crashed' state, it reasserts. This leads to a loop of firmware asserts and it never recovers. Hence to fix this issue, once all devices in the group have been asserted and powered down, reset the MLO global memory region. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-9-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: handle ath12k_core_reset() with hardware groupingAditya Kumar Singh
Currently, in ath12k_core_reset(), the device is powered up immediately after a power down. However, with hardware grouping, when one device asserts, all partner devices also asserts. If there is a delay in processing these asserts, by the time this device powers up, other devices might still be asserting, leading to an overall recovery failure. To prevent this issue, ensure all asserts for a group are processed before initiating the power-up sequence. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-8-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: handle ath12k_core_restart() with hardware groupingAditya Kumar Singh
Currently, when ath12k_core_restart() is called and the ab->is_reset flag is set, it invokes ieee80211_restart_hw() for all hardware in the same group. However, other hardware might still be in the recovery process, making this call inappropriate with grouping into picture. To address this, add a condition to check if the group is ready. If the group is not ready, do not call ieee80211_restart_hw(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-7-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix ath12k_core_pre_reconfigure_recovery() with groupingAditya Kumar Singh
Currently, ath12k_core_pre_reconfigure_recovery() reconfigures all radios within the same group. During grouping and driver going for a recovery, this function is called as many times as there are devices in the group. Consequently, it performs the same reconfiguration multiple times, which is unnecessary. To prevent this, add a check to continue if the action has already been taken. To simplify the management of various flags, the reason for hardware queues being stopped is used as a check instead of introducing a new flag. While at it, also add missing wiphy locks. Wiphy lock is required since ath12k_mac_drain_tx() which is called by ath12k_core_pre_reconfigure_recovery() needs this lock to be held by the caller. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-6-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix firmware assert during reboot with hardware groupingAditya Kumar Singh
At present, during PCI shutdown, the power down is only executed for a single device. However, when operating in a group, all devices need to be powered down simultaneously. Failure to do so will result in a firmware assertion. Hence, introduce a new ath12k_pci_hw_group_power_down() and call it during power down. This will ensure that all partner devices are properly powered down. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-5-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix ATH12K_FLAG_REGISTERED flag handlingAditya Kumar Singh
Commit a5686ae820fa ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()") relocated the setting of the ATH12K_FLAG_REGISTERED flag to the ath12k_mac_register() function. However, this function only accesses the first device (ab) via ag->ab[0], resulting in the flag being set only for the first device in the group. Similarly, ath12k_mac_unregister() only unsets the flag for the first device. The flag should actually be set for all devices in the group to avoid issues during recovery. Hence, move setting and clearing of this flag in the function ath12k_core_hw_group_start() and ath12k_core_hw_group_stop() respectively. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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: a5686ae820fa ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()") Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-4-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix failed to set mhi state error during reboot with hardware ↵Aditya Kumar Singh
grouping With hardware grouping, during reboot, whenever a device is removed, it powers down itself and all its partner devices in the same group. Now this is done by all devices and hence there is multiple power down for devices and hence the following error messages can be seen: ath12k_pci 0002:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0002:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0003:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0003:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0004:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0004:01:00.0: failed to set mhi state: POWER_OFF(3) To prevent this, check if the ATH12K_PCI_FLAG_INIT_DONE flag is already set before powering down. If it is set, it indicates that another partner device has already performed the power down, and this device can skip this step. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-3-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: add reference counting for core attachment to hardware groupAditya Kumar Singh
Currently, driver does not manage reference counting for attaching and detaching cores to/from hardware groups. This can lead to issues when multiple cores are involved. Or with same core, attach/detach is called multiple times back to back. Fix this issue by using reference counting. With that, it is now ensured that the core is properly attached or detached from the hardware group and even back to back calls will not alter the count. Additionally, add some debug logs during the attachment and detachment events for better debugging and tracking. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-2-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix SLUB BUG - Object already free in ath12k_reg_free()Aditya Kumar Singh
During rmmod of ath12k module with SLUB debug enabled, following print is seen - ============================================================================= BUG kmalloc-1k (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in ath12k_reg_build_regd+0x94/0xa20 [ath12k] age=10470 cpu=0 pid=0 __kmalloc_noprof+0xf4/0x368 ath12k_reg_build_regd+0x94/0xa20 [ath12k] ath12k_wmi_op_rx+0x199c/0x2c14 [ath12k] ath12k_htc_rx_completion_handler+0x398/0x554 [ath12k] ath12k_ce_per_engine_service+0x248/0x368 [ath12k] ath12k_pci_ce_workqueue+0x28/0x50 [ath12k] process_one_work+0x14c/0x28c bh_worker+0x22c/0x27c workqueue_softirq_action+0x80/0x90 tasklet_action+0x14/0x3c handle_softirqs+0x108/0x240 __do_softirq+0x14/0x20 Freed in ath12k_reg_free+0x40/0x74 [ath12k] age=136 cpu=2 pid=166 kfree+0x148/0x248 ath12k_reg_free+0x40/0x74 [ath12k] ath12k_core_hw_group_destroy+0x68/0xac [ath12k] ath12k_core_deinit+0xd8/0x124 [ath12k] ath12k_pci_remove+0x6c/0x130 [ath12k] pci_device_remove+0x44/0xe8 device_remove+0x4c/0x80 device_release_driver_internal+0x1d0/0x22c driver_detach+0x50/0x98 bus_remove_driver+0x70/0xf4 driver_unregister+0x30/0x60 pci_unregister_driver+0x24/0x9c ath12k_pci_exit+0x18/0x24 [ath12k] __arm64_sys_delete_module+0x1a0/0x2a8 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 Slab 0xfffffdffc0033600 objects=10 used=6 fp=0xffff000000cdcc00 flags=0x3fffe0000000240(workingset|head|node=0|zone=0|lastcpupid=0x1ffff) Object 0xffff000000cdcc00 @offset=19456 fp=0xffff000000cde400 [...] This issue arises because in ath12k_core_hw_group_destroy(), each device calls ath12k_core_soc_destroy() for itself and all its partners within the same group. Since ath12k_core_hw_group_destroy() is invoked for each device, this results in a double free condition, eventually causing the SLUB bug. To resolve this, set the freed pointers to NULL. And since there could be a race condition to read these pointers, guard these with the available mutex lock. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 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: 6f245ea0ec6c ("wifi: ath12k: introduce device group abstraction") Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-1-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Fix buffer overflow in debugfsDan Carpenter
If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users. Fixes: 3f73c24f28b3 ("wifi: ath12k: Add support to enable debugfs_htt_stats") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/35daefbd-d493-41d9-b192-96177d521b40@stanley.mountain Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Fix a couple NULL vs IS_ERR() bugsDan Carpenter
The devm_memremap() function returns error pointers on error and the ioremap() function returns NULL on error. The error checking here got those flipped around. Fixes: c01d5cc9b9fe ("wifi: ath12k: Power up userPD") Fixes: 6cee30f0da75 ("wifi: ath12k: add AHB driver support for IPQ5332") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/937abc74-9648-4c05-a2c3-8db408b3ed9e@stanley.mountain Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath11k: Use of_property_present() to test property presenceRob Herring (Arm)
The use of of_property_read_u32() isn't really correct as "memory-region" contains phandles (though those happen to be u32s. As it is just testing for property presence, use of_property_present() instead. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250408190211.2505737-2-robh@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Fix WMI tag for EHT rate in peer assocRamya Gnanasekar
Incorrect WMI tag is used for EHT rate update from host to firmware while encoding peer assoc WMI. Correct the WMI tag used for EHT rate update from WMI_TAG_HE_RATE_SET to the proper tag. This ensures firmware does not mistakenly update HE rate during parsing. Found during code review. Compile tested only. Fixes: 5b70ec6036c1 ("wifi: ath12k: add WMI support for EHT peer") Signed-off-by: Ramya Gnanasekar <ramya.gnanasekar@oss.qualcomm.com> Link: https://patch.msgid.link/20250409152341.944628-1-ramya.gnanasekar@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Disable broadcast TWT feature in HE MAC capabilitiesThomas Wu
Currently, the AP does not support the broadcast target wake time (TWT) feature. Therefore, disable the broadcast TWT feature in the HE MAC capabilities element field. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Thomas Wu <quic_wthomas@quicinc.com> Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250409053830.4039467-1-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Introduce check against zero for ahvif->key_cipher in ↵Aaradhana Sahu
ath12k_mac_op_tx() Currently, ahvif->key_cipher is compared with the enum value (WMI_CIPHER_NONE) inside ath12k_mac_op_tx(). However, ahvif->key_cipher is set using the macro value WLAN_CIPHER_SUITE_XXXX which seems inconsistent. To improve code consistency and readability, introduce check against zero for ahvif->key_cipher instead of comparing it with the enum (WMI_CIPHER_NONE). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250403082207.3323938-3-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Resolve multicast packet drop by populating key_cipher in ↵Aaradhana Sahu
ath12k_install_key() Currently, the key_cipher in the ath12k_vif structure, which represents the group cipher of the MLD AP, is populated when the link address matches the ieee80211_vif address within ath12k_install_key(). However, in MLD AP, the link address and ieee80211_vif address can differ. Due to this key_cipher is not populated and multicast packets don't get the correct cipher information and resulting multicast packets drop. To fix this, compare the link address with the arvif->bssid instead of the ieee80211_vif address. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Fixes: 3dd2c68f206ef ("wifi: ath12k: prepare vif data structure for MLO handling") Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250403082207.3323938-2-aaradhana.sahu@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix cleanup path after mhi initRaj Kumar Bhagat
Currently, the 'err_pci_msi_free' label is misplaced, causing the cleanup sequence to be incorrect. Fix this by moving the 'err_pci_msi_free' label to the correct position after 'err_irq_affinity_cleanup'. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00209-QCAHKSWPL_SILICONZ-1 Fixes: a3012f206d07 ("wifi: ath12k: set IRQ affinity to CPU0 in case of one MSI vector") Signed-off-by: Raj Kumar Bhagat <quic_rajkbhag@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250403-ath12k-cleanup-v1-1-ad8f67b0e9cf@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Add support for link specific datapath statsBalamurugan Mahalingam
Add support to record the number of frames enqueued, hardware descriptor type, encapsulation/encryption types used, frames dropped and completed. This is useful for understanding the datapath performance and tune the peak throughput. The link specific stats can be viewed through the below debugfs file cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan1/link_stats link[0] Tx Unicast Frames Enqueued = 9 link[0] Tx Broadcast Frames Enqueued = 78689 link[0] Tx Frames Completed = 78698 link[0] Tx Frames Dropped = 0 link[0] Tx Frame descriptor Encap Type = raw:0 native wifi:78698 ethernet:0 link[0] Tx Frame descriptor Encrypt Type = 0:78698 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0 11:0 link[0] Tx Frame descriptor Type = buffer:78698 extension:0 ------------------------------------------------------ link[1] Tx Unicast Frames Enqueued = 0 link[1] Tx Broadcast Frames Enqueued = 78689 link[1] Tx Frames Completed = 78689 link[1] Tx Frames Dropped = 0 link[1] Tx Frame descriptor Encap Type = raw:0 native wifi:78689 ethernet:0 link[1] Tx Frame descriptor Encrypt Type = 0:78689 1:0 2:0 3:0 4:0 5:0 6:0 7:0 8:0 9:0 10:0 11:0 link[1] Tx Frame descriptor Type = buffer:78689 extension:0 ------------------------------------------------------ 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: Balamurugan Mahalingam <quic_bmahalin@quicinc.com> Link: https://patch.msgid.link/20250409155125.299380-1-quic_bmahalin@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: replace the usage of rx desc with rx_infoP Praneesh
In ath12k_dp_rx_h_mpdu(), during the undecap to native wifi mode, the rx descriptor memory is overwritten. After this function call, any subsequent accesses to rx descriptor related memory yield invalid values. Fix this by replacing instances where rx_desc was used with the pre-cached information in rx_info. This ensures that the values populated from the rx descriptor are accurate and prevents invalid memory access. 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 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> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250402182917.2715596-3-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: add rx_info to capture required field from rx descriptorP Praneesh
In ath12k_dp_rx_h_mpdu(), as part of undecap to native wifi mode, the rx descriptor memory is getting overwritten. After this function call, all the rx descriptor related memory accesses give invalid values. To handle this scenario, introduce a new structure ath12k_dp_rx_info which pre-caches all the required fields from the rx descriptor before calling ath12k_dp_rx_h_ppdu(). This rx_info structure will be used in the next patch. 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 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> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250402182917.2715596-2-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11Merge tag 'wireless-2025-04-11' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Just a handful of fixes, notably - iwlwifi: various build warning fixes (e.g. PM_SLEEP) - iwlwifi: fix operation when FW reset handshake times out - mac80211: drop pending frames on interface down * tag 'wireless-2025-04-11' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: Revert "wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue()" wifi: iwlwifi: mld: Restart firmware on iwl_mld_no_wowlan_resume() error wifi: iwlwifi: pcie: set state to no-FW before reset handshake wifi: wl1251: fix memory leak in wl1251_tx_work wifi: brcmfmac: fix memory leak in brcmf_get_module_param wifi: iwlwifi: mld: silence uninitialized variable warning wifi: mac80211: Purge vif txq in ieee80211_do_stop() wifi: mac80211: Update skb's control block key in ieee80211_tx_dequeue() wifi: at76c50x: fix use after free access in at76_disconnect wifi: add wireless list to MAINTAINERS iwlwifi: mld: fix building with CONFIG_PM_SLEEP disabled wifi: iwlwifi: mld: fix PM_SLEEP -Wundef warning wifi: iwlwifi: mld: reduce scope for uninitialized variable ==================== Link: https://patch.msgid.link/20250411142354.24419-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-11wifi: iwlwifi: mld: Restart firmware on iwl_mld_no_wowlan_resume() errorLukas Wunner
Commit 44605365f935 ("iwlwifi: mld: fix building with CONFIG_PM_SLEEP disabled") sought to fix build breakage, but inadvertently introduced a new issue: iwl_mld_mac80211_start() no longer calls iwl_mld_start_fw() after having called iwl_mld_stop_fw() in the error path of iwl_mld_no_wowlan_resume(). Fix it. Fixes: 44605365f935 ("iwlwifi: mld: fix building with CONFIG_PM_SLEEP disabled") Reported-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Closes: https://lore.kernel.org/r/MW5PR11MB58106D6BC6403845C330C7AAA3A22@MW5PR11MB5810.namprd11.prod.outlook.com/ Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/d3ba1006a1b72ceb58c593fa62b9bd7c73e2e4ed.1744366815.git.lukas@wunner.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-11wifi: iwlwifi: pcie: set state to no-FW before reset handshakeJohannes Berg
The reset handshake attempts to kill the firmware, and it'll go into a pretty much dead state once we do that. However, if it times out, then we'll attempt to dump the firmware to be able to see why it didn't respond. During this dump, we cannot treat it as if it was still running, since we just tried to kill it, otherwise dumping will attempt to send a DBGC stop command. As this command will time out, we'll go into a reset loop. For now, fix this by setting the trans->state to say firmware isn't running before doing the reset handshake. In the longer term, we should clean up the way this state is handled. It's not entirely clear but it seems likely that this issue was introduced by my rework of the error handling, prior to that it would've been synchronous at that point and (I think) not have attempted to reset since it was already doing down. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219967 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219968 Fixes: 7391b2a4f7db ("wifi: iwlwifi: rework firmware error handling") Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250411104054.63aa4f56894d.Ife70cfe997db03f0d07fdef2b164695739a05a63@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-09wifi: ath12k: ahb: Replace del_timer_sync() with timer_delete_sync()Jeff Johnson
A linux-next build error was reported in [1]. This is the result of a treewide timer cleanup [2]. The ath12k AHB support has not yet landed in the tree where the cleanup occurred, and hence a new call to del_timer_sync() was not addressed by the treewide cleanup. So fix that one instance. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://msgid.link/20250408105146.459dfcf5@canb.auug.org.au # [1] Link: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=8fa7292fee5c5240402371ea89ab285ec856c916 # [2] Link: https://patch.msgid.link/20250408-timer_delete_sync-v1-1-4dcb22f71083@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-09wifi: rtw88: Fix the module names printed in dmesgBitterblue Smith
The rtw88 module names all start with the "rtw88_" prefix, but the messages in dmesg mostly use the "rtw_" prefix. The messages from rtw88_8723cs don't even have the underscore. Use the KBUILD_MODNAME macro in every driver. This ensures that the messages in dmesg will always use the module name. Before: Mar 17 15:54:19 ideapad2 kernel: rtw_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6 After: Mar 17 16:33:35 ideapad2 kernel: rtw88_8814au 2-4:1.0: Firmware version 33.6.0, H2C version 6 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/29cd29ba-bc51-4d5b-ad48-a43c6ce72d56@gmail.com
generated by cgit (git 2.34.1) at 2025-07-18 17:39:13 +0000