ath12k: inconsistent regdb for QCN9274

ath12k: inconsistent regdb for QCN9274

[Alexander Wilhelm]

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

Re: ath12k: inconsistent regdb for QCN9274

[Thirusenthil Kumaran J]

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.

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.

Best regards,
Thirusenthil

Re: ath12k: inconsistent regdb for QCN9274

[Alexander Wilhelm]

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@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