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