ath12k: inconsistent regdb for QCN9274

[Thirusenthil Kumaran J]

On 9/29/2026 2:00 PM, Alexander Wilhelm wrote:
> On Fri, Sep 25, 2026 at 01:36:39PM +0530, Thirusenthil Kumaran J wrote:
>> On 9/8/2026 12:16 PM, Alexander Wilhelm wrote:
>>>
>>> Hello Developers,
>>>
>>> I am using QCN9274 chipsets with the `ath12k` driver on my devices. As far as I
>>> can tell, the driver uses the regulatory database from the `board-2.bin` file.
>>> However, some country definitions do not appear to be fully implemented, as the
>>> values differ from those in Linux's standard `wireless-regdb` repository. I even
>>> downloaded the latest `linux-firmware-20260810.tar.xz` and do not see any
>>> related changes there.
>>>
>>> For example, when switching to DE, I see the following values:
>>> * Channels 52-64: 23 dBm; I would expect 20.0 dBm
>>> * Channels 100-140: 30.0 dBm; I would expect 26.0 dBm
>>> * Channels 144-173: (disabled); I would expect 13.0 dBm
>>>
>>> US also appears to be inconsistent:
>>> * Channels 36-48: 30.0 dBm; I would expect 23.0 dBm
>>> * Channels 169-173: (disabled); I would expect 30.0 dBm
>>>
>>> I am aware that `wireless-regdb` is intentionally restrictive in some cases. For
>>> example, there are rules where 26.0 dBm is used instead of 30.0 dBm because it
>>> is implicitly assumed that TPC is not supported. Therefore, some differences may
>>> be expected.
>>>
>>> However, the values above still appear to be incorrect. Could someone at
>>> Qualcomm please investigate this and fix the regulatory information if it is
>>> indeed wrong? If the current behavior is intentional, I would appreciate an
>>> explanation of how these limits are derived, as they do not seem to match either
>>> the `wireless-regdb` entries or the applicable regulatory requirements. Thank
>>> you in advance.
>>>
>>>
>>> Best regards
>>> Alexander Wilhelm
>>>
>>
>> Hi Alexander,
>>
>> Our internal regulatory team is reviewing the source and rationale for
>> these values. We would also like to confirm which BDF was selected on
>> your platform during boot.
> 
> Hi Thirusenthil,
> 
> Thank you for your response. I am using a WLE7002Exx cards from "Compex Systems"
> and have also received the corresponding custom BDFs. I then added them to
> board-2.bin using qca-swiss-army-knife. For the regdb, I am using the default
> version that comes with the kernel (the one with ID 255).
> 
>> Could you please share the following details from the affected platform?
>> - The exact platform/board model, or RDP number if applicable which is
>> used with the QCN9274.
>> - The complete dmesg output from the affected boot.
>>
>> In particular, please include the ath12k QMI target-capability messages
>> containing information similar to:
>>
>> chip_id, chip_family, board_id, soc_id, fw_version,
>>
>> These messages are printed from the 'ath12k_qmi_request_target_cap()'
>> function. They will help us identify the chipset, board ID, SoC, and
>> firmware version, and correlate the selected BDF with the regulatory data.
>>
>> For a quick filtered view, you may also run:
>>
>> dmesg | grep -i -E 'ath12k|board|bdf|chip_id|fw_version|fw_build|soc_id'
>>
>> With these details, we can verify whether the reported channels are
>> included in the selected BDF and continue investigating the regulatory
>> limits.
> 
> The wireless modules are running on our in-house board based on a PowerPC64
> T1023 platform. I am using OpenWrt v25.12.5 with wireless driver backports from
> v6.18.26. The board-2.bin currently originates from v6.12.94. The dmesg output
> (without debug messages) is provided below:
> 
>     user at host-A:~# logread -e ath12k
>     ath12k_pci 0001:01:00.0: BAR 0 [mem 0xc00000000-0xc001fffff 64bit]: assigned
>     ath12k_pci 0001:01:00.0: MSI vectors: 1
>     ath12k_pci 0001:01:00.0: Hardware name: qcn9274 hw2.0
>     ath12k_pci 0002:01:00.0: BAR 0 [mem 0xc10000000-0xc101fffff 64bit]: assigned
>     ath12k_pci 0002:01:00.0: MSI vectors: 1
>     ath12k_pci 0002:01:00.0: Hardware name: qcn9274 hw2.0
>     ath12k_pci 0001:01:00.0: qmi dma allocation failed (29360128 B type 1), will try later with small size
>     ath12k_pci 0001:01:00.0: memory type 10 not supported
>     ath12k_pci 0001:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x1005 soc_id 0x401a2200
>     ath12k_pci 0001:01:00.0: fw_version 0x160484db fw_build_timestamp 2025-12-09 20:09 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>     ath12k_pci 0002:01:00.0: qmi dma allocation failed (29360128 B type 1), will try later with small size
>     ath12k_pci 0002:01:00.0: memory type 10 not supported
>     ath12k_pci 0002:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x1008 soc_id 0x401a2200
>     ath12k_pci 0002:01:00.0: fw_version 0x160484db fw_build_timestamp 2025-12-09 20:09 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>     ath12k_pci 0001:01:00.0: leaving PCI ASPM disabled to avoid MHI M2 problems
>     debugfs: File 'ath12k' in directory 'phy0' already present!
>     ath12k_pci 0002:01:00.0: leaving PCI ASPM disabled to avoid MHI M2 problems
>     debugfs: File 'ath12k' in directory 'phy1' already present!
> 
> 
> Best regards
> Alexander Wilhelm


Hi Alexander,

Thank you for providing the platform details and dmesg output.
The logs help us identify the two QCN9274 devices and their reported
board IDs. They also confirm the firmware being used.

As mentioned earlier, our internal regulatory team is checking the
reported TX power restrictions against the regulatory database and
reviewing the source and rationale for the DE and US entries.

Since you mentioned that you are using custom BDFs from Compex Systems
and added them to board-2.bin, having the exact final board-2.bin or the
corresponding custom BDF files would be very helpful. This would allow
us to inspect the hardware-specific frequency and channel limits and
rule out any issue specific to the custom BDF.

If possible, could you also let us know whether the same behavior is
observed with the unmodified default BDF? If so, we can continue the
analysis from our side without requiring the custom BDF.

Please share the dmesg output from the default-BDF run as well,
including the board_id and firmware-information messages.

Best regards,
Thirusenthil