Skip to content

Conversation

@miaoqing-quic
Copy link
Contributor

No description provided.

Baochen Qiang and others added 17 commits January 7, 2026 13:46
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-1-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-2-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-3-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-4-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-5-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-6-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-7-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-8-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
… 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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-9-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-10-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
… 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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-11-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-12-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-13-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-16-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-17-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
…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 <miaoqing.pan@oss.qualcomm.com>
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 <baochen.qiang@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-wireless/20251218-ath12k-support-qcc2072-v1-19-87928cf8e547@oss.qualcomm.com/
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
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.

1 participant