summaryrefslogtreecommitdiff
path: root/drivers/net/wireless
AgeCommit message (Collapse)Author
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
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>
generated by cgit (git 2.34.1) at 2025-09-24 06:41:26 +0000