FROMLIST: wifi: ath11k: Fix failure to connect to a 6 GHz AP #503
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… compatible For M.2 WLAN chips, there is no suitable DTS node to specify the firmware-name property. In addition, assigning firmware for the M.2 PCIe interface causes chips that do not use usecase specific firmware to fail. Therefore, abandoning the approach of specifying firmware in DTS. As an alternative, propose a static lookup table mapping device compatible to firmware names. Currently, only WCN6855 HW2.1 requires this. For details on usecase specific firmware, see: https://lore.kernel.org/all/[email protected]/. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: edbbc64 ("wifi: ath11k: support usercase-specific firmware overrides") Signed-off-by: Miaoqing Pan <[email protected]> Link: https://lore.kernel.org/linux-wireless/[email protected]/
Currently, the FBC image is a non-standard ELF file that contains a single
ELF header, followed by segments for SBL, and WLAN FW. However, TME-L
(Trust Management Engine Lite) supported devices (eg. QCC2072) requires
separate ELF headers for SBL and WLAN FW segments due to TME-L image
authentication requirement.
Current image format contains two sections in a single binary:
- First 512KB: ELF header + SBL segments
- Remaining: WLAN FW segments
The TME-L supported image format contains two sections with two elf
headers in a single binary:
- First 512KB: First ELF header + SBL segments
- Remaining: Second ELF header + WLAN FW segments
Download behavior:
- Legacy: 1. First 512KB via BHI (ELF header + SBL)
2. Full image via BHIe
- TME-L: 1. First 512KB via BHI (First ELF header + SBL)
2. Remaining via BHIe (Second ELF header + WLAN FW segments)
Add standard_elf_image flag to mhi_controller_config to indicate TME-L
supported image format. When set, MHI skips the first 512KB during WLAN FW
download over BHIe as it is loaded in BHI phase.
Reviewed-by: Baochen Qiang <[email protected]>
Signed-off-by: Mayank Rana <[email protected]>
Co-developed-by: Qiang Yu <[email protected]>
Signed-off-by: Qiang Yu <[email protected]>
Link: https://lore.kernel.org/mhi/20251201-wlan_image_load_skip_512k-v3-1-bedb5498a58a@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <[email protected]>
Currently offset of PCI window register address is defined as 0x310c which is same across existing chips. However QCC2072 has a different offset 0x3278. In order to make the window selection logic work for QCC2072 as well, change to initialize this parameter per device at the probe time. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-1-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
The entry of REO CMD ring of existing chips has a 64 bit TLV header, hence below functions take a 64 bit TLV assumption by default reo_init_cmd_ring reo_cmd_encode_hdr However this is not the case for QCC2072 of which the TLV is 32 bit, meaning above functions don't work for it. Rename/refactor above functions to prepare for QCC2072 support: Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-2-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
The entry of REO status ring of existing chips has a 64 bit TLV header, however this is not the case for QCC2072 of which the TLV is 32 bit. Refactor above functions to prepare for QCC2072 support, this is done by removing TLV length assumption and offloading TLV decoding work to a newly added callback _reo_status_dec_tlv_hdr. This way each chip can register its own handler hence can do the work accordingly. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-3-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
…tion For single pdev device like WCN7850/QCC2072, preferred_hw_mode is initialized to WMI_HOST_HW_MODE_SINGLE. Later when firmware sends supported modes to host, each mode is compared with the initial one and if the priority of the new mode is higher, update the parameter and store mode capability. For WCN7850, this does not result in issue, as one of the supported mode indeed has a higher priority. However the only available mode of QCC2072 at this stage is WMI_HOST_HW_MODE_SINGLE, which fails the comparison, hence mode capability is not stored. Subsequently driver initialization fails. Fix it by accepting a mode with the same priority. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-4-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
…parsing For single pdev device, 320 MHz bandwidth support is reported only in capability of WMI_HOST_HW_MODE_SINGLE mode, hence commit d4e244c ("wifi: ath12k: enable 320 MHz bandwidth for 6 GHz band in EHT PHY capability for WCN7850") relaxed the condition check in ath12k_wmi_tlv_mac_phy_caps_ext() to allow SINGLE mode getting parsed in ath12k_wmi_tlv_mac_phy_caps_ext_parse(). Since SINGLE mode is not assumed to be preferred, the function returns unconditionally after parsing 320 MHz support. This works for WCN7850 because it prefers another mode indeed, while it breaks QCC2072 since it prefers SINGLE mode. Due to the unconditional return, the subsequent EHT parsing is skipped. Consequently EHT related features are disabled. Refactor it by moving 320 MHz parsing to ath12k_wmi_tlv_mac_phy_caps_ext(), before the mode checking. This makes the code more straightforward, and work for both WCN7850 and QCC2072. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-5-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
Currently ath12k_pull_mac_phy_cap_svc_ready_ext() assumes only one band supported in each phy, hence it skips 5 GHz band if 2 GHz band support is detected. This does not work for device which gets only one phy but has both bands supported, such as QCC2072. Change to check each band individually to fix this issue. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-6-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
Add hardware registers and populate hw_regs field in ath12k_wifi7_hw_ver_map for QCC2072. Note for some registers not defined and not used by QCC2072, a magic value is assigned. Also populate other fields to be the same with WCN7850. Among them, however, QCC2072 requires different HAL ops and descriptor size, both will be updated in upcoming patches. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-7-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
Add hardware parameters for QCC2072, these parameters are directly taken from WCN7850, with exceptions to hardware name, revision, firmware directory, iova_mask and RFKILL parameter set. Compared to WCN7850, QCC2072 doesn't require aligned IOVA when transmitting packets, hence iova_mask is set to zero. Besides, WCN7850 has a dedicated GPIO for RFKILL purpose, however QCC2072 has it coupled with WLAN_EN pin. For QCC2072, host is not allowed to send any RFKILL configuration info to firmware, or firmware crashes. Hence those parameters are all cleared to skip configuring command. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-8-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
… for QCC2072 Firmware (amss.bin) of QCC2072 is a standard ELF image, however those of other chips are not. MHI subsystem supports both format, but by default takes it as non-standard. Flag this to MHI subsystem to avoid firmware loading failure. Also refine hardware parameter dereferencing by defining a new local pointer. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-9-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
…type QCC2072 requires a new type of QMI target memory named LPASS_SHARED_V01, add support for it. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-10-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
… image for QCC2072 QCC2072 requires another firmware image named aux_ucode.bin, add support to download it. Add a new hardware parameter download_aux_ucode to make sure other chips are not affected. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-11-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
QCC2072 has different HAL descriptors hence require different HAL handling, compared to other chips. Add support for this. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-12-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
Due to HAL descriptors, QCC2027 has different offsets of MPDU start tag and MSDU end tag, compared with other chips. Hence add new hardware ops structure for QCC2072. All ops are directly taken from WCN7850, with the exception to rxdma_ring_sel_config, which needs a new function ath12k_dp_rxdma_ring_sel_config_qcc2072() to handle the difference mentioned above. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-13-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
…mmand Currently the number of channels can be sent in a single WMI command is calculated based on the maximum message length of the target, this results in WMI exchange hang for QCC2072 as its firmware can not support those many channels in a single command. Add a limit to avoid this issue. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-16-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
…ware Peer meta data version is currently not delivered to firmware, resulting in QCC2072 data path issues. Parse it from service ready ext2 event and send to firmware in WMI init command. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-17-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
…inition for QCC2072 The definition of PCIE_LOCAL_REG_QRTR_NODE_ID in QCC2072 is incorrect, which causes the QMI connection to fail when ATH12K_FW_FEATURE_MULTI_QRTR_ID is enabled. To resolve this issue, move it to the hardware register table. Note IPQ5332 is not affected as it is not PCIe based device. Tested-on: QCC2072 hw1.0 PCI CI_WLAN.COL.1.0-01668.1-QCACOLSWPL_V1_TO_SILICONZ-9 Signed-off-by: Miaoqing Pan <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-18-87928cf8e547@oss.qualcomm.com/
Add QCC2072's PCI device ID to the table such that it can be probed, also populate some parameters when probing. Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0-01560-QCACOLSWPL_V1_TO_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 Signed-off-by: Baochen Qiang <[email protected]> Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-19-87928cf8e547@oss.qualcomm.com/ Signed-off-by: Miaoqing Pan <[email protected]>
STA fails to connect to a 6 GHz AP with the following errors: ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1 wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING) ath11k_reg_handle_chan_list() treats the update as redundant and returns -EINVAL. That causes the connection attempt to fail. Avoid unnecessary validation during association. Apply the regulatory redundant check only when the power type is IEEE80211_REG_UNSET_AP, which only occurs during core initialization. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41 Signed-off-by: Qian Zhang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
STA fails to connect to a 6 GHz AP with the following errors:
ath11k_pci 0000:01:00.0: failed to handle chan list with power type 1
wlp1s0: deauthenticating from c8:a3:e8:dd:41:e3 by local choice (Reason: 3=DEAUTH_LEAVING)
ath11k_reg_handle_chan_list() treats the update as redundant and
returns -EINVAL. That causes the connection attempt to fail.
Avoid unnecessary validation during association. Apply the regulatory
redundant check only when the power type is IEEE80211_REG_UNSET_AP,
which only occurs during core initialization.
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
Signed-off-by: Qian Zhang [email protected]
CRs-Fixed: 4366717