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

[Jeff Johnson <jeff.johnson@oss.qualcomm.com>]

On 9/9/2026 2:46 AM, Baochen Qiang wrote:
> 
> 
> 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?

Working through my backlog. Is there any action on this?