Skip to content

ath11k: tolerate non-PASS regulatory status from QSDK firmware#1103

Closed
firasshaari wants to merge 1 commit into
Telecominfraproject:mainfrom
firasshaari:firasshaari/ath11k-dfs-regulatory-fix
Closed

ath11k: tolerate non-PASS regulatory status from QSDK firmware#1103
firasshaari wants to merge 1 commit into
Telecominfraproject:mainfrom
firasshaari:firasshaari/ath11k-dfs-regulatory-fix

Conversation

@firasshaari
Copy link
Copy Markdown
Contributor

Problem

CIG WF196 (IPQ8074 + QCN9074) running ApNos v5.0.0 (OpenWrt 25.12.3) fails to start 5 GHz on any DFS channel:

ath11k c000000.wifi1: Failed to set the requested Country regulatory setting
ath11k c000000.wifi1: failed to process regulatory info from received event
ath11k c000000.wifi1: vdev start resp error status 4 (invalid regdomain)

Non-DFS channels (36, 149) work. DFS channels (52, 64, 100, 116) all fail. Regression from ApNos 4.2.4 on the same hardware + firmware.

Root cause

QSDK firmware (WLAN.HK.2.7.0.1-01744) sends WMI_REG_CHAN_LIST_CC_EVENT with status_code != REG_SET_CC_STATUS_PASS (typically REG_CURRENT_ALPHA2_NOT_FOUND).

In backports-6.1.24 (ApNos 4.2.4): the regulatory event handler had no status_code check -- it processed whatever rules the firmware sent regardless of status.

The current QSDK backports added a check at wmi.c that rejects the event entirely with -EINVAL when status is non-PASS. This leaves the firmware DFS regulatory context broken -- firmware then refuses DFS vdev_start because it never received a valid channel list for DFS bands.

Fix

Downgrade the fatal check to a debug log and continue processing the regulatory rules the firmware provided:

 if (reg_info->status_code != REG_SET_CC_STATUS_PASS) {
-    ath11k_warn(ab, "Failed to set the requested Country regulatory setting\n");
-    return -EINVAL;
+    ath11k_dbg(ab, ATH11K_DBG_REG,
+               "regulatory status %d, continuing with available rules\n",
+               reg_info->status_code);
 }

Patch location: feeds/qca-wifi-6/mac80211/patches/pending/a-106-ath11k-tolerate-non-PASS-regulatory-status-from-QSDK-FW.patch

Verification

Tested on CIG WF196 (IPQ8074 + QCN9074) with firmware WLAN.HK.2.7.0.1-01744:

Channel Before After
36 (non-DFS) Works Works
52 (DFS UNII-2) Fails status 4 Works
64 (DFS UNII-2) Fails status 4 Works
116 (DFS UNII-2C) Fails status 4 Works
dmesg "Failed to set Country" Every boot Gone
dmesg "status 4 invalid regdomain" Every DFS attempt Gone

Scope

Affects all QCA wifi-6 APs using QSDK-era firmware (WLAN.HK.2.x) with the current QSDK backports. Does not affect QCA wifi-7 or MediaTek targets.

Note: This PR is based on main~1 (3f602f67) to avoid ef629637 which introduced a broken ucentral-schema Makefile (missing PKG_SOURCE_VERSION). That commit should be reverted separately.

QSDK firmware (e.g. WLAN.HK.2.7.0.1-01744) sends WMI_REG_CHAN_LIST_CC_EVENT
with status_code != REG_SET_CC_STATUS_PASS (typically ALPHA2_NOT_FOUND).

The host-side regulatory event handler in wmi.c rejects the event entirely
with -EINVAL, leaving the firmware DFS regulatory context broken.
Consequence: 5 GHz DFS vdev_start fails with status 4 (invalid regdomain).
Non-DFS channels work because firmware is lenient there.

In the earlier backports-6.1.24 driver (ApNos 4.2.4), this status_code
check did not exist -- regulatory processing went through a different path
that ignored the firmware status and processed whatever rules it sent.

Fix: downgrade the fatal check to a debug log and continue processing the
regulatory rules the firmware provided. The firmware includes usable rules
even with a non-PASS status.

Tested on CIG WF196 (IPQ8074 + QCN9074) with WLAN.HK.2.7.0.1-01744.
DFS channels 52, 64, and 116 start successfully after this patch.

Signed-off-by: Firas Shaari <firas@80211networks.com>
@blogic blogic force-pushed the main branch 2 times, most recently from 8fceb40 to 9fd154c Compare May 27, 2026 07:33
@blogic
Copy link
Copy Markdown
Contributor

blogic commented May 27, 2026

I cannot find the corresponding Jira ticket

@blogic
Copy link
Copy Markdown
Contributor

blogic commented May 27, 2026

I have the feeling that this is just papering over a deeper issue. just ignoring the errors from the FW feels utterly wrong. the FW will not be ensuring the regd compliant restrictions after this patch.

@firasshaari
Copy link
Copy Markdown
Contributor Author

@blogic sounds good. I have assigned this ticket to the CIG team. Let's wait for their feedback before we spend more time on this.

@blogic blogic closed this Jun 8, 2026
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.

2 participants