ath12k: inconsistent regdb for QCN9274
Alexander Wilhelm
alexander.wilhelm at westermo.com
Sun Oct 11 23:20:14 PDT 2026
On Fri, Oct 09, 2026 at 03:06:04PM +0530, Thirusenthil Kumaran J wrote:
> 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.
Hi Thirusenthil,
Unfortunately, I am not able to perform a test using a default BDF. I downloaded
the latest board-2.bin from linux-firmware (linux-firmware-20260916.tar.xz), but
it does not contain the board IDs reported by the modules I'm using, namely
4122, 4101, or 4104. I had also assumed that the default regdb (ID 255) would
contain all regulatory information. For example, here is the output from the
linux-wireless regdb in my current kernel:
global
country DE: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(5945 - 6425 @ 320), (N/A, 23), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
And for comparison, here is the output reported by the PHY of one of the
modules:
phy#0 (self-managed)
country DE: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A), NO-80MHZ, NO-160MHZ, NO-320MHZ
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW, NO-320MHZ
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW, NO-320MHZ
(5490 - 5590 @ 80), (N/A, 30), (0 ms), DFS, AUTO-BW, NO-320MHZ
(5590 - 5650 @ 40), (N/A, 30), (600000 ms), DFS, AUTO-BW, NO-320MHZ
(5650 - 5710 @ 40), (N/A, 30), (0 ms), DFS, AUTO-BW, NO-320MHZ
(5945 - 6425 @ 320), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
As an example, you can see that the 5 GHz range only extends up to 5710 MHz and
then resumes at 5945 MHz. As a result, I can only operate up to channel 140 and
not channel 173 as expected, which is available when using the US regulatory
domain.
> Please share the dmesg output from the default-BDF run as well,
> including the board_id and firmware-information messages.
>
> Best regards,
> Thirusenthil
Best regards
Alexander Wilhelm
More information about the ath12k
mailing list