Re: [PATCH ath-current] wifi: ath12k: fix frequency range for single-pdev devices

[Baochen Qiang <baochen.qiang@oss.qualcomm.com>]

On 7/20/2026 5:25 PM, Shenghan Gao wrote:
> The update sequence is as follows.
> 
> ath12k_regd_update() first resets ar->freq_range to zero. On the
> tested WCN7850 under the CN regulatory domain, the 2 GHz branch
> calculates a valid range, so the first call to
> ath12k_mac_update_freq_range() sets ar->freq_range to 2402-2482 MHz.
> 
> The existing 5 GHz branch is skipped because ar->supports_6ghz is true.
> 
> When the new regulatory domain is built, reg_freq_6ghz.end_freq is
> reset to zero. Since the CN regulatory event contains no 6 GHz rules,
> it remains zero. The 6 GHz branch therefore calculates freq_high as
> zero, and ath12k_mac_update_freq_range() returns without extending the
> existing range.
> 
> Consequently, ar->freq_range remains 2402-2482 MHz, and the subsequent
> channel-list update filters out all 5 GHz channels.

Thanks, now I get the root cause.

However the change of this patch looks more like a workaround rather than a proper fix:

Current radio frequency logic has been architecturally wrong from the start. Ever since
657b0c72c4ad introduced reg_freq_*, the entire purpose of this code has been to compute a
per-radio frequency range (to advertise each radio's own Frequency Range to user space —
Idx 0/Idx 1 in iw phyX info). Since the quantity is per-radio, reg_freq_2ghz/5ghz/6ghz
should not live in struct ath12k_base (per-device). Storing a per-radio quantity in a
per-device field is a layer mismatch, and every problem below derives from it.

Two problems caused by keeping them in ath12k_base:

(a) A cross-phy race that silently drops a range. Firmware sends WMI_REG_CHAN_LIST_CC_EXT
per phy. build_regd() resets all three ab->reg_freq_* to {INT_MAX, 0} and refills only its
own phy's band on every event, while regd_update() runs per-ar off a workqueue reading
that shared per-device state. A later phy's event can reset, e.g., reg_freq_5ghz back to
{INT_MAX, 0} before an earlier radio's regd_update_work runs; that radio then computes
freq_high = min(high_5ghz_chan, 0) = 0 and the range is silently dropped by
ath12k_mac_update_freq_range(). This is a real shared-state race.

(b) It forces the ar->supports_6ghz proxy — which is where your change comes from. Because
ab->reg_freq_* is per-device, regd_update() can't tell from it which band this radio
covers, so it falls back to ar->supports_6ghz to guess whether this is the 6 GHz-only
radio. That proxy only holds on split-pdev; on single-pdev (one pdev covers 5+6 GHz,
supports_6ghz=true) it breaks, which is exactly why you had to add the || single_pdev_only
exception to rescue 5 GHz. The awkward compound gate is rooted in using a per-device proxy
to decide per-radio band ownership.

Based on above, I would suggest making reg_freq_2ghz/5ghz/6ghz per-radio, in struct
ath12k_pdev. ath12k_pdev is the driver's canonical per-radio object (1:1 with a radio,
holding ar/cap/mac_addr), and this operating range is a property of the radio — so it
belongs there, right next to cap (the HW freq limits), which is the same class of data (HW
capability vs. the rule-intersected actual range). Both problems then dissolve:

- (a) is gone: each radio's range is isolated; a later phy's event can no longer clobber
another's.
- (b) is gone: the gate can ask the ground-truth question — "did this radio receive reg
rules for this band?" (end_freq != 0) — with no supports_6ghz proxy:

  if (supported_bands & WMI_HOST_WLAN_5GHZ_CAP &&
      ar->pdev->reg_freq_5ghz.end_freq) {

> 
> With this patch, the 5 GHz branch also runs for single-pdev devices and
> merges the valid 5 GHz range, extending ar->freq_range to
> 2402-5835 MHz.
> 
> Baochen Qiang <baochen.qiang@oss.qualcomm.com> 于2026年7月20日周一 16:34写道：
>>
>>
>>
>> On 7/15/2026 2:52 PM, Shenghan Gao wrote:
>>> Commit 0d777aa2ca77 ("wifi: ath12k: fix mac pdev frequency range update")
>>> made ath12k_regd_update() handle each supported band independently.
>>> However, it uses WMI band capability values as indices into
>>> pdev->cap.band[]. Those values are bit flags, while cap.band[] is indexed
>>> by enum nl80211_band. As a result, the 2.4 GHz lookup reads the
>>> 5 GHz entry, while the 5 GHz lookup reads the 60 GHz entry.
>>>
>>> Also, the 5 GHz range is skipped whenever the radio supports 6 GHz. This
>>> is valid when 5 and 6 GHz belong to separate pdevs, but not for single-pdev
>>> devices such as WCN7850, where the same pdev covers both bands. After a
>>> regulatory update, 5 GHz is therefore omitted from ar->freq_range and later
>>> filtered out of the channel list sent to firmware.
>>>
>>> On the tested WCN7850, the 11d regulatory update left the frequency range
>>> at 2402-2482 MHz and sent 13 channels to firmware. A subsequent 5 GHz scan
>>
>> can you share more details on how the frequency range is updated to cover only 2 GHz band ?
>>
>>> failed with WMI_SCAN_REASON_INTERNAL_FAILURE. With both ranges combined,
>>> the range is 2402-5835 MHz and 26 channels are sent to firmware.
>>>
>>> Index cap.band[] with NL80211_BAND_* and update 5 GHz for single-pdev
>>> devices even when 6 GHz is supported.
>>>
>>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
>>>
>>> Fixes: 0d777aa2ca77 ("wifi: ath12k: fix mac pdev frequency range update")
>>> Cc: stable@vger.kernel.org
>>> Assisted-by: Codex:GPT-5.6 Sol
>>> Signed-off-by: Shenghan Gao <gsh20040816@gmail.com>
>>> ---
>>> Testing notes:
>>>
>>> - Runtime testing was performed on WCN7850 under the CN regulatory domain.
>>> - 2.4 and 5 GHz scanning and 5 GHz association were verified.
>>> - 6 GHz operation was not tested because it is unavailable under the CN
>>>   regulatory domain.
>>> - QCC2072 was not tested because the hardware was not available.
>>>
>>>  drivers/net/wireless/ath/ath12k/reg.c | 7 ++++---
>>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath12k/reg.c b/drivers/net/wireless/ath/ath12k/reg.c
>>> index 89abf2e87ad1..c3bb1df2b1e2 100644
>>> --- a/drivers/net/wireless/ath/ath12k/reg.c
>>> +++ b/drivers/net/wireless/ath/ath12k/reg.c
>>> @@ -300,7 +300,7 @@ int ath12k_regd_update(struct ath12k *ar, bool init)
>>>
>>>       if (supported_bands & WMI_HOST_WLAN_2GHZ_CAP) {
>>>               if (ab->hw_params->single_pdev_only) {
>>> -                     phy_id = ar->pdev->cap.band[WMI_HOST_WLAN_2GHZ_CAP].phy_id;
>>> +                     phy_id = ar->pdev->cap.band[NL80211_BAND_2GHZ].phy_id;
>>>                       reg_cap = &ab->hal_reg_cap[phy_id];
>>>               }
>>>
>>> @@ -310,9 +310,10 @@ int ath12k_regd_update(struct ath12k *ar, bool init)
>>>               ath12k_mac_update_freq_range(ar, freq_low, freq_high);
>>>       }
>>>
>>> -     if (supported_bands & WMI_HOST_WLAN_5GHZ_CAP && !ar->supports_6ghz) {
>>> +     if (supported_bands & WMI_HOST_WLAN_5GHZ_CAP &&
>>> +         (!ar->supports_6ghz || ab->hw_params->single_pdev_only)) {
>>>               if (ab->hw_params->single_pdev_only) {
>>> -                     phy_id = ar->pdev->cap.band[WMI_HOST_WLAN_5GHZ_CAP].phy_id;
>>> +                     phy_id = ar->pdev->cap.band[NL80211_BAND_5GHZ].phy_id;
>>>                       reg_cap = &ab->hal_reg_cap[phy_id];
>>>               }
>>>
>>>
>>> base-commit: a1a21995c2e1cc2ca6b2226cfe4f5f018370182a
>>