Skip to content

Conversation

@zhuhangtian
Copy link

Per PdM request, to support QCC2072 connectivity which is done bringup based on ath-next code base, we must use ath-next for external release. This PR is to sync with ath-next

hangtian and others added 30 commits February 2, 2026 18:25
Revert below 3 commits:
597aa8b "UPSTREAM: wifi: ath12k: Fix timeout error during ..."
ed30fd7 "UPSTREAM: wifi: ath12k: Make firmware stats reset ..."
05581be "FROMLIST: wifi: ath11k: add usecase firmware handling..."

Signed-off-by: hangtian <[email protected]>
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(),
pm_runtime_autosuspend() and pm_request_autosuspend() now include a call
to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to
pm_runtime_mark_last_busy().

Signed-off-by: Sakari Ailus <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
wcn36xx_smd_update_scan_params() last use was removed in 2020 by
commit 5973a29 ("wcn36xx: Fix software-driven scan")

Remove it.

This leaves the wcn36xx_hal_update_scan_params_req_ex and
wcn36xx_hal_update_scan_params_resp structs unused.

Remove them, together with the unused
wcn36xx_hal_update_scan_params_req.

Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Acked-by: Loic Poulain <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
… ring

Add a counter "reo_excep_msdu_buf_type" in
ath12k_debugfs_dump_device_dp_stats() to account for packets dropped
due to unexpected MSDU buffer types in the RX error path. These
packets are discarded to prevent incorrect parsing and potential
kernel crashes. This helps in debugging and monitoring RX error
handling behavior.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Signed-off-by: Sarika Sharma <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
…eacon

Mac80211 schedules CSA finalize work twice during a channel switch: first
during the reserved switch phase and again during the finalize phase.
The beacon content is updated only during the second schedule, which occurs
after the reserved switch completes. However, the ath12k driver attempts to
bring up the VDEV during the channel switch callback
(ath12k_mac_update_vif_chan()), which leads to premature installation of
stale beacon templates before the updated content is available.

This premature VDEV bring-up causes outdated beacon information to be
broadcast, which can result in updated channel parameters during the
transition. In MBSSID scenarios, this behavior is particularly problematic
because the transmitting interface's beacon must be updated before
non-transmitting interfaces are brought up. Failing to do so can lead to
beacon mismatches across interfaces.

Introduce a is_csa_in_progress flag to defer VDEV_UP until CSA finalize is
complete. Set this flag during the channel switch callback when CSA is
active. In bss_info_changed(), check this flag and issue VDEV_UP only
after the beacon template has been updated.

Ensure that in MBSSID cases, the transmitting interface is brought up
first, followed by all non-transmitting interfaces. This ordering makes
sure correct beacon propagation and avoids stale beacon installation
during CSA transitions.

Additionally, move the call to ath12k_mac_update_peer_puncturing_width()
before VDEV bring-up during CSA handling. This ensures that the puncturing
bitmap and bandwidth settings are applied before the VDEV is brought up.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

Fixes: 8c6faa5 ("wifi: ath12k: add MBSSID beacon support")
Signed-off-by: Aditya Kumar Singh <[email protected]>
Signed-off-by: Maharaja Kennadyrajan <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Currently, in ext_rx_stats, the NSS value is taken directly from
the firmware, which results in incorrect mapping:
        4x4, 3x3, 2x2, 1x1 SS are incorrectly updated as 3x3, 2x2,
1x1, 0x0 SS respectively.

Fix the issue by incrementing the NSS value by 1 while updating
the PPDU info to ensure accurate spatial stream statistics.

Remove the redundant +1 increment in the radiotap header when monitor
mode is enabled to prevent double counting.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1

Signed-off-by: Thiraviyam Mariyappan <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Some systems such as live-image or installer require the firmware
information for each module declared by MODULE_FIRMWARE(), which is
currently missing in ath12k driver.

For addressing it, this patch adds the MODULE_FIRMWARE() entries.
Like ath11k driver, we can just put the currently used firmware
entries for QCN9274 and WCN7850 with wildcards.

Signed-off-by: Takashi Iwai <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Existing tools like myftm use 'legacy' test command API. Similarly
to ath11k and ath12k, we want to support raw TLV payload submitted
from the test tool. This requires segmenting the TLV payload and
encapsulating it within a WMI command. The opposite operation needs
to be done upon corresponding event receiving.

Tested-on: WCN3990 hw1.0 WLAN.HL.3.3.7.c2-00931-QCAHLSWMTPLZ-1

Signed-off-by: Loic Poulain <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
A forthcoming change necessitates that these functions be defined prior to
their usage. Therefore, relocate them now as a preparatory step for the
upcoming modifications.

Compile tested only.

Signed-off-by: Aditya Kumar Singh <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/20251017-add_tx_power_insertion_support-v1-1-f08feacfca93@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
…al helper

Refactor ath11k_mac_op_get_txpower() by introducing a new internal function
ath11k_mac_handle_get_txpower(), which assumes the caller holds the
appropriate lock. This prepares the codebase for future change where the
internal function may be invoked directly with the lock already acquired,
improving modularity and lock handling consistency.

No functional change intended.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1

Signed-off-by: Aditya Kumar Singh <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/20251017-add_tx_power_insertion_support-v1-2-f08feacfca93@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
For certain action frames like the TPC Report IE in the spectrum management
TPC Report action frame, and in the Radio Measurement Link Measurement
Report action frame there is a requirement to fill in the current
and max Tx power of the device in the packet.

Add support to populate these fields in the relevant packets.

In software-encrypted cases such as PMF, skip insertion since the packets
are already encrypted and cannot be modified.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1

Signed-off-by: Aditya Kumar Singh <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/20251017-add_tx_power_insertion_support-v1-3-f08feacfca93@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
Now that driver is capable of inserting Tx power, advertise the support
for the same to upper layers.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-02146-QCAHKSWPL_SILICONZ-1

Signed-off-by: Aditya Kumar Singh <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/20251017-add_tx_power_insertion_support-v1-4-f08feacfca93@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
The checkpatch script is reporting multiple instances of:
	Argument 'x' is not used in function-like macro

Fix these by renaming the argument to match the usage. In the process,
also add parenthesis to the usage to avoid MACRO_ARG_PRECEDENCE
issues.

Compile tested only.

Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Add support for handling BSS color collision events reported by firmware.

There are two scenarios where a BSS color collision may be detected:
1. The AP's MAC detects the collision directly, and firmware reports a
   BSS color collision event to the host.
2. A STA associated with the AP detects the collision. The notification
   frame from the peer is routed directly to the AP firmware, which handles
   it and sends the BSS color collision event to the host.

Add logic to parse and handle such events, and pass the data
up to mac80211.

Unlike CSA, firmware does not provide an offload mechanism for BSS color
change. Instead, the color change process is triggered via beacon offload
TX completion events sent by firmware.

BSS color feature is enabled depending on service flag advertised by
firmware, based on which color change functionality is invoked.

This change builds upon the following ath11k patch.
commit 886433a ("ath11k: add support for BSS color change")

Tested-on: WCN7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00011-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1

Signed-off-by: Wei Zhang <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
…lement

Add a lockdep assertion to verify that ab->base_lock is held prior to
allocating a REO update element in ath12k_dp_prepare_reo_update_elem().
This helps detect potential concurrency issues during development and
improves code robustness.
Compiled tested only.

Signed-off-by: Sarika Sharma <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Currently, functions in mac.c for setting GI and LTF rates are
specifically for HE rates.

Remove any mention of "HE" in such functions in order to allow for
other modes to utilize the functions. The intention is to prepare for
the addition of EHT GI and LTF fixed rate settings.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Signed-off-by: Muna Sinada <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Add EHT rate handling to the existing rate functions that validate,
prepare and set rates.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Co-developed-by: Aloka Dixit <[email protected]>
Signed-off-by: Aloka Dixit <[email protected]>
Signed-off-by: Muna Sinada <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Add EHT MCS/NSS rate functionality to peer association. As part of
ath12k_peer_assoc_h_eht() add the calculation of EHT MCS/NSS using
intersection of link_sta and phy capability.

ath12k_mac_max_eht_mcs_nss() function is utilized when comparing the
max NSS of link STA and phy capability since in split phy case, phy
supports max NSS of 2 for 5G band.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Co-developed-by: Vishal Kumar <[email protected]>
Signed-off-by: Vishal Kumar <[email protected]>
Co-developed-by: Aloka Dixit <[email protected]>
Signed-off-by: Aloka Dixit <[email protected]>
Signed-off-by: Muna Sinada <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Add EHT functionality to set fixed GI/LTF parameters.
Add new wmi vdev parameter id for EHT LTF

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Signed-off-by: Muna Sinada <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Extend ath12k_mac_op_set_bitrate_mask() to handle EHT rates.
Create and pass EHT mask containing MCS and NSS along with EHT GI and
LTF when calling ath12k_mac_set_rate_params()

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Co-developed-by: Aaradhana Sahu <[email protected]>
Signed-off-by: Aaradhana Sahu <[email protected]>
Signed-off-by: Muna Sinada <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Fixed rate is set for STAs that are associated. This will be done
during association or with ath12k_sta_rc_update_wk().

Add EHT fixed rate setting for STAs by adding call to
ath12k_mac_set_peer_eht_fixed_rate() during the times fixed rate is
set for STAs. This new function sets EHT fixed rate for a peer, which
sends WMI command with the updated MCS/NSS rate using
WMI_PEER_PARAM_FIXED_RATE command id.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Co-developed-by: Aaradhana Sahu <[email protected]>
Signed-off-by: Aaradhana Sahu <[email protected]>
Signed-off-by: Muna Sinada <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Initialize the pm_qos_request structure using = {} instead of memset() in
ath10k_download_fw(). This ensures the structure is properly zeroed before
passing it to cpu_latency_qos_add_request(), and improves efficiency by
avoiding an explicit runtime memset.

Signed-off-by: Zhongqiu Han <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Initialize the bmi_target_info structure using = {} at declaration time
instead of calling memset() in each bus-specific code path. This
simplifies the code and avoids an explicit memset.

Signed-off-by: Zhongqiu Han <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Currently, ath12k_fw_stats_reset() is called in
ath12k_mac_get_fw_stats() before fetching the required stats from the
firmware. However, ath12k_open_bcn_stats() requests firmware stats for
each enabled BSS individually. Since the firmware stats are reset before
fetching, only the last BSS's data is displayed.

Also, in ath12k_mac_op_get_txpower(), ath12k_mac_op_sta_statistics(), and
ath12k_mac_op_link_sta_statistics(), after getting the stats from the
firmware, the reset function is not called until the next firmware
stats are requested or while unloading the module. Hence, the stats buffer
will not be freed until one of the above sequences is executed. However,
in ath12k_open_vdev_stats(), ath12k_open_bcn_stats() and
ath12k_open_pdev_stats(), firmware stats are reset after copying the
necessary data in ath12k_wmi_fw_stats_dump().

This leads to inconsistent usage of ath12k_fw_stats_reset() for
freeing the firmware stats.

Avoid these discrepancies by making it the caller's responsibility to
free the stats buffer, thereby removing the need to free the stats buffer
in ath12k_mac_get_fw_stats() and ath12k_wmi_fw_stats_dump().

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Signed-off-by: Manish Dharanenthiran <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Currently, for beacon_stats, ath12k_mac_get_fw_stats() is called
for each started BSS on the specified hardware.
ath12k_mac_get_fw_stats() will wait for the fw_stats_done completion
after fetching the requested data from firmware. For the beacon_stats,
fw_stats_done completion will be set only when stats are received for
all BSSes. However, for other stats like vdev_stats or pdev_stats, there
is one request to the firmware for all enabled BSSes. Since beacon_stats
is fetched individually for all BSSes enabled in that pdev, waiting for
the completion event results in a timeout error when multiple BSSes are
enabled.

Avoid this by completing the fw_stats_done immediately after
updating the requested BSS's beacon stats in the list. Subsequently,
this list will be used to display the beacon stats for all enabled
BSSes in the requested pdev.

Additionally, remove 'num_bcn_recvd' from the ath12k_fw_stats struct
as it is no longer needed.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Fixes: 9fe4669 ("wifi: ath12k: Request beacon stats from firmware")
Signed-off-by: Manish Dharanenthiran <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Refactor pci.c to split common and hardware family specific components.
Retain shared logic such as probe and initialization sequences in common
pci.c to support reuse across device families and move Wi-Fi 7 specific
initialization and configuration to a new pci_wifi7.c file. Register
device specific routines via callbacks to keep the common PCI code
generic and extensible for future hardware families.
This improves maintainability and prepare the codebase for additional
device family support.

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: Kiran Venkatappa <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Relocate Copy Engine (CE) assignment logic from ce.c to a new ce_wifi7.c
file to consolidate Wi-Fi 7 specific CE configuration in one place.
Move CE service map and target configuration from hw.c to ce_wifi7.c.

This reorganization improves code clarity and modularity by isolating
device-specific logic. It is part of a broader effort to separate
common and hardware-specific code into distinct modules.

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: Kiran Venkatappa <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Relocate Wi-Fi 7 specific WMI configuration from shared codebase to a new
target-specific file. Isolate WMI settings per target to improve
modularity and maintainability.

This change is part of a broader effort to separate hardware-dependent
logic into standalone modules, paving the way for cleaner support of
multiple hardware families

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: Kiran Venkatappa <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Baochen Qiang and others added 29 commits February 2, 2026 18:33
In case of multi-link connection, WCN7850 firmware crashes due to WoW
offloads enabled on both primary and secondary links.

Change to do it only on primary link to fix it.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1

Fixes: 32f7b19 ("wifi: ath12k: support MLO as well if single_chip_mlo_support flag is set")
Signed-off-by: Baochen Qiang <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20251103-ath12-primary-link-wow-v1-1-3cf523dc09f0@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
…R module

Channel Frequency Response (CFR) module will be initialized only when
the following criteria passes:
 * Enabled CFR support for the hardware through the hardware param
   'cfr_support'
 * WMI service enabled for the CFR support
   'WMI_TLV_SERVICE_CFR_CAPTURE_SUPPORT'

Also, provide a configuration option CONFIG_ATH11K_CFR to enable CFR
feature support during the compilation time.

CFR module initialization includes Direct Buffer(DB) ring initialization
where hardware uses the DB ring buffers to copy CFR data to host.
Number of buffers and buffer size of the ring is based on the DB ring
capabilities advertised by the firmware through WMI service ready.
Also ring configurations are sent to firmware through
ath11k_dbring_wmi_cfg_setup().

Predefine ath11k_cfr_dma_hdr, ath11k_look_up_table, and ath11k_cfr
structs and fields for subsequent patches.

Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Signed-off-by: Venkateswara Naralasetty <[email protected]>
Co-developed-by: Yu Zhang (Yuriy) <[email protected]>
Signed-off-by: Yu Zhang (Yuriy) <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Signed-off-by: Qian Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Provide debugfs interfaces support to config CFR from the user space.

To enable/disable cfr feature use command,

echo <val> > /sys/kernel/debug/ieee80211/phyX/ath11k/enable_cfr

where, val: 0 to disable CFR and 1 to enable CFR.

To enable CFR capture for associated peers,

echo "<val> <bw> <periodicity> <method>"
 >
/sys/kernel/debug/ieee80211/phyX/netdev\:wlanx/stations/<mac>/cfr_capture

val: 0 - stop CFR capture
     1 - start CFR capture
bw: CFR capture bandwidth
     0 - 20MHZ
     1 - 40MHZ
     2 - 80MHZ
Periodicity: Periodicity at which hardware is expected to collect CFR
dump.
     0 - single shot capture.
     non zero - for Periodic captures (value must be multiple of 10 ms)
method: Method used by hardware to collect the CFR dump.
     0 - from the ACKs of QOS NULL packets.

Also, send the required WMI commands to the firmware based on the CFR
configurations.

Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Signed-off-by: Venkateswara Naralasetty <[email protected]>
Co-developed-by: Yu Zhang (Yuriy) <[email protected]>
Signed-off-by: Yu Zhang (Yuriy) <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Signed-off-by: Qian Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Provide debugfs interfaces support to config unassociated client CFR
from the user space.

To enable CFR capture for unassociated clients,

echo "<mac address> <val> <periodicity>"
 > /sys/kernel/debug/ieee80211/phyX/ath11k/cfr_unassoc

Mac address: mac address of the client.
Val: 0 - start CFR capture
     1 - stop CFR capture
Periodicity: Periodicity at which hardware is expected to collect CFR
dump.
     0 - single shot capture.
     non zero - for Periodic captures (value must be multiple of 10 ms)

Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Signed-off-by: Venkateswara Naralasetty <[email protected]>
Co-developed-by: Yu Zhang (Yuriy) <[email protected]>
Signed-off-by: Yu Zhang (Yuriy) <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Signed-off-by: Qian Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Provide a relayfs interface to collect the CFR dump from the user space.

'/sys/kernel/debug/ieee80211/phyX/ath11k/cfr_capture' is exposed to user
space to get CFR data.

CFR format to user space:
 ___________________________________________
| CFR header | CFR payload | CFR tail data |
|____________|_____________|_______________|

CFR header contains the following fields,

* Start magic number 0xDEADBEAF - 4 bytes
* vendor id - 4 bytes
* cfr metadata version - 1 byte
* cfr data version - 1 byte
* device type - 1 byte
* platform type - 1 byte
* CFR metadata length - 4 bytes
* metadata - 92 bytes
        peer mac - 6 bytes
        capture status - 1 byte (1 for success 0 for failure)
        capture_bw - 1 byte
        channel_bw - 1 byte
        phy_mode - 1 byte
        prim20_chan - 2 bytes
        center_freq1 - 2 bytes
        center_freq2 - 2 bytes
        capture_mode - 1 byte
        capture_type - 1 byte
        sts_count - 1 byte
        num_rx_chain - 1 byte
        timestamp - 4 bytes
        length - 4 bytes
        chain_rssi - 32 bytes (4 bytes for each chain)
        chain_phase - 16 bytes (2 bytes for each chain)
        cfo_measurement - 4 bytes
        agc_gain - 8 bytes (1 bytes for each chain)
        rx_start_ts - 4 bytes

CFR payload:

CFR payload contains 8bytes of ucode header followed by the tone
information. Tone order is positive tones, followed by PHY memory
garbage, followed by negative tones. Dummy tones are uploaded to make
number of tones always integer number of 64. Number of tones is not
preamble type dependent.

Each CFR tone has 14-bit I component and 14-bit Q component and is sign
extended to 16-bit I/Q. Two tones are packed into one 64-bit unit as:

[63:0] = [Tone1_Q(63:48) Tone1_I(47:32) Tone0_Q(31:16) Tone0_I(15:0)]

CFR tail: end magic number 0xBEAFDEAD

Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Signed-off-by: Venkateswara Naralasetty <[email protected]>
Co-developed-by: Yu Zhang (Yuriy) <[email protected]>
Signed-off-by: Yu Zhang (Yuriy) <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Signed-off-by: Qian Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Add handler for WMI_PDEV_DMA_RING_BUF_RELEASE_EVENT which indicates CFR
data availability in the DB ring.

Add CFR data processing from DB ring buffers. Use correlate_and_relay
API to match CFR data with metadata from WMI_PEER_CFR_CAPTURE_EVENT.

Release buffer to userspace through relayfs on successful correlation,
otherwise hold buffer waiting for matching WMI event from firmware.

Add new debug masks:
 - ATH11K_DBG_CFR:      Enables CFR-related debug logs.
 - ATH11K_DBG_CFR_DUMP: Enables detailed CFR data dump for analysis.

Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Signed-off-by: Venkateswara Naralasetty <[email protected]>
Co-developed-by: Yu Zhang (Yuriy) <[email protected]>
Signed-off-by: Yu Zhang (Yuriy) <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Signed-off-by: Qian Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
Firmware sends CFR meta data through the WMI event
WMI_PEER_CFR_CAPTURE_EVENT. Parse the meta data coming from the firmware
and invoke correlate_and_relay function to correlate the CFR meta data
with the CFR payload coming from the other WMI event
WMI_PDEV_DMA_RING_BUF_RELEASE_EVENT.

Release the buffer to user space once correlate and relay return
success.

Tested-on: IPQ8074 hw2.0 PCI IPQ8074 WLAN.HK.2.5.0.1-00991-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Signed-off-by: Venkateswara Naralasetty <[email protected]>
Co-developed-by: Yu Zhang (Yuriy) <[email protected]>
Signed-off-by: Yu Zhang (Yuriy) <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Signed-off-by: Qian Zhang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[email protected]>
".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It
is initialized in, core.c, a different file than the array. This
spaghetti-like relation is fragile and not obvious. Accidentally
setting ".max_tx_ring" too high leads to a hard to track out-of-
bounds access and memory corruption.

There is a small ambiguity on the meaning of "max_tx_ring":
 - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3)
 - The highest number to use for array indexing (there are 3 rings)

Clarify this dependency by moving ".max_tx_ring" adjacent to the array
".tcl2wbm_rbm_map", and name it "num_tx_rings". Use ARRAY_SIZE()
instead of #defines to initialize the length field.

The intent is to make the code easier to understand rather than fix
an existing bug.

Signed-off-by: Alexandru Gagniuc <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Reviewed-by: Baochen Qiang <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jeff Johnson <[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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-1-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[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

        ath12k_wifi7_hal_reo_init_cmd_ring()
        ath12k_wifi7_hal_reo_cmd_queue_stats()
        ath12k_wifi7_hal_reo_cmd_flush_cache()
        ath12k_wifi7_hal_reo_cmd_update_rx_queue()

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:

Rename the first one to ath12k_wifi7_hal_reo_init_cmd_ring_tlv64() to
better reflect what it is doing. There will be a 32 bit variant when
QCC2072 support is in place.

For the last ones, remove TLV length assumption and offload TLV encoding
work to a newly added callback _reo_cmd_enc_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.3

Signed-off-by: Baochen Qiang <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-2-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
The entry of REO status ring of existing chips has a 64 bit TLV header,
hence below functions take a 64 bit TLV assumption by default

        ath12k_wifi7_dp_rx_process_reo_status()
        ath12k_wifi7_hal_reo_status_queue_stats()
        ath12k_wifi7_hal_reo_flush_queue_status()
        ath12k_wifi7_hal_reo_flush_cache_status()
        ath12k_wifi7_hal_reo_unblk_cache_status()
        ath12k_wifi7_hal_reo_flush_timeout_list_status()
        ath12k_wifi7_hal_reo_desc_thresh_reached_status()
        ath12k_wifi7_hal_reo_update_rx_reo_queue_status()

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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-3-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-4-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-5-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-6-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-7-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-8-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-9-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-10-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
QCC2072 has different HAL descriptors hence require different HAL
handling, compared to other chips. Add support for this.

REO CMD/status ring handling is currently using the 64 bit ops

	.reo_init_cmd_ring = ath12k_wifi7_hal_reo_init_cmd_ring_tlv64,
	.reo_cmd_enc_tlv_hdr = ath12k_hal_encode_tlv64_hdr,
	.reo_status_dec_tlv_hdr = ath12k_hal_decode_tlv64_hdr,

these will be updated to use 32 bit variants 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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-11-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-12-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
As far as REO CMD ring is concerned, there are two differences between
QCC2072 and the existing chips:

For the first, the TLV header of ring descriptor for QCC2072 is 32 bits
while 64 bits for existing chips.

For the second, QCC2072 has different hal_reo_get_queue_stats,
hal_reo_flush_cache and hal_reo_update_rx_queue structures. Take
hal_reo_get_queue_stats as an example:

QCC2072:
struct hal_reo_get_queue_stats_qcc2072 {
        struct hal_reo_cmd_hdr cmd;
        [...]
        __le32 rsvd0[6];
} __packed;

QCN9274/WCN7850:
struct hal_reo_get_queue_stats {
        struct hal_reo_cmd_hdr cmd;
        [...]
        __le32 rsvd0[6];
        __le32 tlv64_pad;
} __packed;

Note there is no tlv64_pad at the end for QCC2072, but all other
former fields share the same layout.

These make different ring entry size, so that parameter has to be updated
with respect to existing chips. This is done in the newly introduced
ath12k_hal_srng_create_config_qcc2072() function, which first creates all
ring configs by utilizing ath12k_hal_srng_create_config_wcn7850() and then
updates the individual field.

Besides, the REO command TLV encoding also need to be corrected because of
the different TLV bits. This is done by introducing a 32 bit variant for
each of the existing 64 bit callback.

Note the hal_reo_get_queue_stats_qcc2072 structure is introduced for the
purpose of calculating ring entry size. Existing hal_reo_get_queue_stats
structure gets used elsewhere even for QCC2072. This is working because
the only difference is the tlv64_pad field that is located at the end and
not getting used, hence can be ignored.

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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-13-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
For QCC2072 below REO status descriptors are different compared with
QCN9274/WCN7850:

        hal_reo_get_queue_stats_status
        hal_reo_flush_queue_status
        hal_reo_flush_cache_status
        hal_reo_unblock_cache_status
        hal_reo_flush_timeout_list_status
        hal_reo_desc_thresh_reached_status

Take hal_reo_get_queue_stats_status as an example:

QCC2072:
struct hal_reo_get_queue_stats_status_qcc2072 {
        __le32 tlv32_padding;
        struct hal_reo_get_queue_stats_status status;
} __packed;

QCN9274/WCN7850:
struct hal_reo_get_queue_stats_status;

Besides, QCC2072 has a 32 bits TLV header while QCN9274/WCN7850 has 64.

This means that there is no difference between these 3 devices in layout
of actual fields, because they all start after a 8 bytes offset

QCC2072:
	{
		struct hal_tlv_hdr tlv;
		__le32 tlv32_padding;
		struct hal_reo_get_queue_stats_status status;
	}

QCN9274/WCN7850:
	{
		struct hal_tlv_64_hdr tlv;
		struct hal_reo_get_queue_stats_status status;
	}

Therefore current implementation luckily works for QCC2072 as well.
However it leads to misunderstanding, which should be avoided.

So add individual REO status ring handling for QCC2072.

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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-14-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-15-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-16-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
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]>
Signed-off-by: Baochen Qiang <[email protected]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-17-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
QCC2072 is a PCI based device that is very much like WCN7850, the major
difference is that QCC2072 has only one phy hence does not support DBS.
With previous patches handling such similarity and difference, it is now
ready to finally enable supporting this device.

Add QCC2072's ID to the PCI device ID table, to allow it getting probed
hence enable support. Also populate some necessary 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]>
Reviewed-by: Vasanthakumar Thiagarajan <[email protected]>
Link: https://patch.msgid.link/20260112-ath12k-support-qcc2072-v2-18-fc8ce1e43969@oss.qualcomm.com
Signed-off-by: Jeff Johnson <[email protected]>
… 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]/
Wrong P2P device link id value of 0 was introduced in ath12k_mac_op_tx() by [1].

During the P2P negotiation process, there is only one scan vdev with link ID 15.
Currently, the device link ID is incorrectly set to 0 in ath12k_mac_op_tx()
during the P2P negotiation process, which leads to TX failures.

Set the correct P2P device link ID to 15 to fix the TX failure issue.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Fixes: 648a121 ("wifi: ath12k: ath12k_mac_op_tx(): MLO support") # [1]
Signed-off-by: Yingying Tang <[email protected]>
Link: https://lore.kernel.org/linux-wireless/[email protected]/
Scan finish workqueue was introduced in __ath12k_mac_scan_finish() by [1].

During ath12k_mac_op_cancel_remain_on_channel(), scan state is set to
ABORTING and should be reset to IDLE in the queued work. However,
wiphy_work_cancel() is called before exiting
ath12k_mac_op_cancel_remain_on_channel(), which prevents the work
from running and leaves the state in ABORTING. This blocks all
subsequent scan requests.

Replace wiphy_work_cancel() with wiphy_work_flush() to ensure the
queued work runs and scan state is reset to IDLE.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3

Fixes: 3863f01 ("wifi: ath12k: symmetrize scan vdev creation and deletion during HW scan") # [1]
Signed-off-by: Yingying Tang <[email protected]>
Link: https://lore.kernel.org/linux-wireless/[email protected]/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.