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

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

On 8/3/2026 4:36 PM, Baochen Qiang wrote:
> 
> 
> 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) {

Shenghan, any thoughts on the suggestion?