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

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

[Shenghan Gao]

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
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
-- 
2.55.0

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

[Baochen Qiang]

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

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

[Shenghan Gao]

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.

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
>

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

[Baochen Qiang]

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
>>

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

[Baochen Qiang]

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?

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

[Jeff Johnson]

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?

[PATCH ath-current] wifi: ath12k: fix lost 5 GHz range by tracking reg ranges per radio

[Ahmed Essam]

ath12k_reg_build_regd() records the frequency span covered by the
received reg rules in ab->reg_freq_{2,5,6}ghz. Those fields live in
struct ath12k_base, but firmware sends WMI_REG_CHAN_LIST_CC_EXT per
radio, and ath12k_regd_update() uses them to compute the frequency
range of a single radio (ar->freq_range). This causes two problems.

First, ath12k_regd_update() cannot tell which bands a radio received
rules for, so it uses ar->supports_6ghz as a proxy: the 5 GHz range is
skipped for any radio that supports 6 GHz. That is only valid for
split-pdev devices. On single-pdev devices such as WCN7850 one radio
covers 2 GHz, 5 GHz and 6 GHz. When firmware switches to a country
without 6 GHz rules, for example after an 11d update to CN or EG,
ar->freq_range collapses to 2402-2482 MHz and
ath12k_reg_update_chan_list() drops every 5 GHz channel from the list
sent to firmware. From then on firmware no longer scans 5 GHz, a
5 GHz-only scan request fails ("received scan start failure event"),
and 5 GHz networks disappear from scan results, typically shortly after
boot. They stay gone until the driver is reloaded or firmware moves to
a country that has 6 GHz rules.

Second, by code inspection, build_regd() resets all three per-device
ranges on every event, so on multi-radio devices an event for one radio
can wipe the range of another radio whose regd_update_work has not run
yet, silently dropping a band.

Move reg_freq_{2,5,6}ghz into struct ath12k_pdev and fill them for the
radio identified by reg_info->phy_id. In ath12k_regd_update(), include
a band only if this radio registered that band and received reg rules
for it, instead of guessing from ar->supports_6ghz. Checking the
registered band is needed because a radio can receive rules for bands
it does not operate on, e.g. the 6 GHz radio of a split-pdev device.

Also fix the reg_cap lookup for single-pdev devices: pdev->cap.band[]
is indexed by enum nl80211_band, but was indexed with the
WMI_HOST_WLAN_*_CAP bit flags, so the 2 GHz lookup used the 5 GHz
entry and the 5 GHz lookup used the unset 60 GHz entry. Refresh
reg_cap for the 6 GHz band as well, as is done for 2 GHz and 5 GHz.

With ATH12K_DBG_MAC enabled on WCN7850 and the firmware switching to
EG, the range before this change is:

  mac pdev 0 freq limit updated. New range 2402->2482 MHz

and after it:

  mac pdev 0 freq limit updated. New range 2402->2482 MHz
  mac pdev 0 freq limit updated. New range 2402->5330 MHz

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3

Fixes: 657b0c72c4ad ("wifi: ath12k: Fix frequency range in driver")
Fixes: 13324cecbb2c ("wifi: ath12k: Update frequency range if reg rules changes")
Fixes: 0d777aa2ca77 ("wifi: ath12k: fix mac pdev frequency range update")
Cc: stable@vger.kernel.org
Reported-by: Shenghan Gao <gsh20040816@gmail.com>
Closes: https://lore.kernel.org/all/20260715065218.41232-1-gsh20040816@gmail.com/
Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Assisted-by: Claude:claude-opus-5-5 sparse
Signed-off-by: Ahmed Essam <mrmrmidoessam@gmail.com>
---

Notes:
    Jeff, sorry for the duplicate: a test send reached you a few minutes
    ago without the lists.
    
    This picks up Shenghan Gao's patch "wifi: ath12k: fix frequency range
    for single-pdev devices" [1], reworked as Baochen suggested in review
    [2]: reg_freq_* are now per radio, and each band is gated on whether
    the radio received rules for it instead of on ar->supports_6ghz. On top
    of that suggestion, the band must also be registered on the radio,
    since the 6 GHz pdev of a split-pdev device receives rules for all
    bands.
    
    Shenghan, I hope you don't mind me picking this up after the thread
    went quiet. I kept your band-index fix and credited your report.
    
    Testing:
    - WCN7850 (single-pdev) with the firmware above. Firmware sets the
      country to EG via 11d about 7 s after the driver loads.
      Before: freq_range drops to 2402->2482 MHz after the EG update, a
      5 GHz-only scan is rejected ("received scan start failure event"),
      and all 5 GHz networks are gone from scan results after about a
      minute.
      After: the range is 2402->5330 MHz, a 5 GHz-only scan returns 26 BSSes,
      5 GHz networks stayed visible for the whole 26 minute run while
      associated on 2.4 GHz, and association to a 5 GHz AP works.
    - Built for x86_64 with W=1; checkpatch --strict and sparse report
      nothing new.
    
    Not tested: split-pdev devices such as QCN9274, and 6 GHz operation (EG
    has no 6 GHz rules). The split-pdev handling is based on reading the
    code only.
    
    AI assistance: I used Claude (claude-opus-5-5) to investigate the
    problem on my machine, write the patch following Baochen's suggestion,
    draft this message and run the tests above. I reviewed the change and
    tested it on my hardware.
    
    [1] https://lore.kernel.org/all/20260715065218.41232-1-gsh20040816@gmail.com/
    [2] https://lore.kernel.org/all/9dd4e992-5810-429f-bc54-036c4eb276a7@oss.qualcomm.com/

 drivers/net/wireless/ath/ath12k/core.h | 20 +++++----
 drivers/net/wireless/ath/ath12k/mac.c  | 12 ++---
 drivers/net/wireless/ath/ath12k/reg.c  | 61 ++++++++++++++++----------
 3 files changed, 56 insertions(+), 37 deletions(-)

diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 93fd227b4d19..b48d39c5db5c 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -850,6 +850,11 @@ struct mlo_timestamp {
 	u32 mlo_comp_timer;
 };
 
+struct ath12k_reg_freq {
+	u32 start_freq;
+	u32 end_freq;
+};
+
 struct ath12k_pdev {
 	struct ath12k *ar;
 	u32 pdev_id;
@@ -857,6 +862,13 @@ struct ath12k_pdev {
 	struct ath12k_pdev_cap cap;
 	u8 mac_addr[ETH_ALEN];
 	struct mlo_timestamp timestamp;
+
+	/* Frequency ranges covered by the reg rules last received for
+	 * this radio, per band. end_freq is 0 if no rules were received.
+	 */
+	struct ath12k_reg_freq reg_freq_2ghz;
+	struct ath12k_reg_freq reg_freq_5ghz;
+	struct ath12k_reg_freq reg_freq_6ghz;
 };
 
 struct ath12k_fw_pdev {
@@ -871,11 +883,6 @@ struct ath12k_board_data {
 	size_t len;
 };
 
-struct ath12k_reg_freq {
-	u32 start_freq;
-	u32 end_freq;
-};
-
 struct ath12k_mlo_memory {
 	struct target_mem_chunk chunk[ATH12K_QMI_WLANFW_MAX_NUM_MEM_SEG_V01];
 	int mlo_mem_size;
@@ -1147,9 +1154,6 @@ struct ath12k_base {
 	/* Denote whether MLO is possible within the device */
 	bool single_chip_mlo_support;
 
-	struct ath12k_reg_freq reg_freq_2ghz;
-	struct ath12k_reg_freq reg_freq_5ghz;
-	struct ath12k_reg_freq reg_freq_6ghz;
 	const struct ath12k_mem_profile_based_param *profile_param;
 	enum ath12k_qmi_mem_mode target_mem_mode;
 
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index da2ba1f39244..a11eb3e2a593 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -14263,9 +14263,9 @@ static int ath12k_mac_setup_channels_rates(struct ath12k *ar,
 		}
 
 		freq_low = max(reg_cap->low_2ghz_chan,
-			       ab->reg_freq_2ghz.start_freq);
+			       ar->pdev->reg_freq_2ghz.start_freq);
 		freq_high = min(reg_cap->high_2ghz_chan,
-				ab->reg_freq_2ghz.end_freq);
+				ar->pdev->reg_freq_2ghz.end_freq);
 
 		ath12k_mac_update_ch_list(ar, band,
 					  reg_cap->low_2ghz_chan,
@@ -14308,9 +14308,9 @@ static int ath12k_mac_setup_channels_rates(struct ath12k *ar,
 			band->bitrates = ath12k_a_rates;
 
 			freq_low = max(reg_cap->low_5ghz_chan,
-				       ab->reg_freq_6ghz.start_freq);
+				       ar->pdev->reg_freq_6ghz.start_freq);
 			freq_high = min(reg_cap->high_5ghz_chan,
-					ab->reg_freq_6ghz.end_freq);
+					ar->pdev->reg_freq_6ghz.end_freq);
 
 			ath12k_mac_update_ch_list(ar, band,
 						  reg_cap->low_5ghz_chan,
@@ -14365,9 +14365,9 @@ static int ath12k_mac_setup_channels_rates(struct ath12k *ar,
 			}
 
 			freq_low = max(reg_cap->low_5ghz_chan,
-				       ab->reg_freq_5ghz.start_freq);
+				       ar->pdev->reg_freq_5ghz.start_freq);
 			freq_high = min(reg_cap->high_5ghz_chan,
-					ab->reg_freq_5ghz.end_freq);
+					ar->pdev->reg_freq_5ghz.end_freq);
 
 			ath12k_mac_update_ch_list(ar, band,
 						  reg_cap->low_5ghz_chan,
diff --git a/drivers/net/wireless/ath/ath12k/reg.c b/drivers/net/wireless/ath/ath12k/reg.c
index 89abf2e87ad1..17232392071a 100644
--- a/drivers/net/wireless/ath/ath12k/reg.c
+++ b/drivers/net/wireless/ath/ath12k/reg.c
@@ -269,10 +269,11 @@ static void ath12k_copy_regd(struct ieee80211_regdomain *regd_orig,
 int ath12k_regd_update(struct ath12k *ar, bool init)
 {
 	struct ath12k_wmi_hal_reg_capabilities_ext_arg *reg_cap;
-	u32 phy_id, freq_low, freq_high, supported_bands;
+	u32 phy_id, freq_low, freq_high;
 	struct ath12k_hw *ah = ath12k_ar_to_ah(ar);
 	struct ieee80211_hw *hw = ah->hw;
 	struct ieee80211_regdomain *regd, *regd_copy = NULL;
+	struct ath12k_pdev *pdev = ar->pdev;
 	int ret, regd_len, pdev_id;
 	struct ath12k_base *ab;
 	long time_left;
@@ -288,43 +289,55 @@ int ath12k_regd_update(struct ath12k *ar, bool init)
 		 */
 	}
 
-	supported_bands = ar->pdev->cap.supported_bands;
 	reg_cap = &ab->hal_reg_cap[ar->pdev_idx];
 
 	/* Possible that due to reg change, current limits for supported
 	 * frequency changed. Update it. As a first step, reset the
 	 * previous values and then compute and set the new values.
+	 *
+	 * Only bands that this radio operates on and received reg rules
+	 * for contribute. A radio may receive rules for bands it does not
+	 * operate on, e.g. the 6 GHz radio of a split-pdev device.
 	 */
 	ar->freq_range.start_freq = 0;
 	ar->freq_range.end_freq = 0;
 
-	if (supported_bands & WMI_HOST_WLAN_2GHZ_CAP) {
+	if (ar->mac.sbands[NL80211_BAND_2GHZ].channels &&
+	    pdev->reg_freq_2ghz.end_freq) {
 		if (ab->hw_params->single_pdev_only) {
-			phy_id = ar->pdev->cap.band[WMI_HOST_WLAN_2GHZ_CAP].phy_id;
+			phy_id = pdev->cap.band[NL80211_BAND_2GHZ].phy_id;
 			reg_cap = &ab->hal_reg_cap[phy_id];
 		}
 
-		freq_low = max(reg_cap->low_2ghz_chan, ab->reg_freq_2ghz.start_freq);
-		freq_high = min(reg_cap->high_2ghz_chan, ab->reg_freq_2ghz.end_freq);
+		freq_low = max(reg_cap->low_2ghz_chan, pdev->reg_freq_2ghz.start_freq);
+		freq_high = min(reg_cap->high_2ghz_chan, pdev->reg_freq_2ghz.end_freq);
 
 		ath12k_mac_update_freq_range(ar, freq_low, freq_high);
 	}
 
-	if (supported_bands & WMI_HOST_WLAN_5GHZ_CAP && !ar->supports_6ghz) {
+	if (ar->mac.sbands[NL80211_BAND_5GHZ].channels &&
+	    pdev->reg_freq_5ghz.end_freq) {
 		if (ab->hw_params->single_pdev_only) {
-			phy_id = ar->pdev->cap.band[WMI_HOST_WLAN_5GHZ_CAP].phy_id;
+			phy_id = pdev->cap.band[NL80211_BAND_5GHZ].phy_id;
 			reg_cap = &ab->hal_reg_cap[phy_id];
 		}
 
-		freq_low = max(reg_cap->low_5ghz_chan, ab->reg_freq_5ghz.start_freq);
-		freq_high = min(reg_cap->high_5ghz_chan, ab->reg_freq_5ghz.end_freq);
+		freq_low = max(reg_cap->low_5ghz_chan, pdev->reg_freq_5ghz.start_freq);
+		freq_high = min(reg_cap->high_5ghz_chan, pdev->reg_freq_5ghz.end_freq);
 
 		ath12k_mac_update_freq_range(ar, freq_low, freq_high);
 	}
 
-	if (supported_bands & WMI_HOST_WLAN_5GHZ_CAP && ar->supports_6ghz) {
-		freq_low = max(reg_cap->low_5ghz_chan, ab->reg_freq_6ghz.start_freq);
-		freq_high = min(reg_cap->high_5ghz_chan, ab->reg_freq_6ghz.end_freq);
+	if (ar->mac.sbands[NL80211_BAND_6GHZ].channels &&
+	    pdev->reg_freq_6ghz.end_freq) {
+		/* 6 GHz is reported as part of the 5 GHz band capability */
+		if (ab->hw_params->single_pdev_only) {
+			phy_id = pdev->cap.band[NL80211_BAND_5GHZ].phy_id;
+			reg_cap = &ab->hal_reg_cap[phy_id];
+		}
+
+		freq_low = max(reg_cap->low_5ghz_chan, pdev->reg_freq_6ghz.start_freq);
+		freq_high = min(reg_cap->high_5ghz_chan, pdev->reg_freq_6ghz.end_freq);
 
 		ath12k_mac_update_freq_range(ar, freq_low, freq_high);
 	}
@@ -645,6 +658,7 @@ ath12k_reg_build_regd(struct ath12k_base *ab,
 		      enum wmi_vdev_type vdev_type,
 		      enum ieee80211_ap_reg_power power_type)
 {
+	struct ath12k_pdev *pdev = &ab->pdevs[reg_info->phy_id];
 	struct ieee80211_regdomain *new_regd = NULL;
 	struct ath12k_reg_rule *reg_rule, *reg_rule_6ghz;
 	u32 flags, reg_6ghz_number, max_bw_6ghz;
@@ -709,14 +723,15 @@ ath12k_reg_build_regd(struct ath12k_base *ab,
 		   alpha2, ath12k_reg_get_regdom_str(new_regd->dfs_region),
 		   reg_info->dfs_region, num_rules);
 
-	/* Reset start and end frequency for each band
+	/* Reset start and end frequency for each band of the radio this
+	 * event belongs to. reg_info->phy_id has already been validated.
 	 */
-	ab->reg_freq_5ghz.start_freq = INT_MAX;
-	ab->reg_freq_5ghz.end_freq = 0;
-	ab->reg_freq_2ghz.start_freq = INT_MAX;
-	ab->reg_freq_2ghz.end_freq = 0;
-	ab->reg_freq_6ghz.start_freq = INT_MAX;
-	ab->reg_freq_6ghz.end_freq = 0;
+	pdev->reg_freq_5ghz.start_freq = INT_MAX;
+	pdev->reg_freq_5ghz.end_freq = 0;
+	pdev->reg_freq_2ghz.start_freq = INT_MAX;
+	pdev->reg_freq_2ghz.end_freq = 0;
+	pdev->reg_freq_6ghz.start_freq = INT_MAX;
+	pdev->reg_freq_6ghz.end_freq = 0;
 
 	/* Update reg_rules[] below. Firmware is expected to
 	 * send these rules in order(2G rules first and then 5G)
@@ -728,7 +743,7 @@ ath12k_reg_build_regd(struct ath12k_base *ab,
 			max_bw = min_t(u16, reg_rule->max_bw,
 				       reg_info->max_bw_2g);
 			flags = ath12k_get_bw_reg_flags(reg_info->max_bw_2g);
-			ath12k_reg_update_freq_range(&ab->reg_freq_2ghz, reg_rule);
+			ath12k_reg_update_freq_range(&pdev->reg_freq_2ghz, reg_rule);
 		} else if (reg_info->num_5g_reg_rules &&
 			   (j < reg_info->num_5g_reg_rules)) {
 			reg_rule = reg_info->reg_rules_5g_ptr + j++;
@@ -743,7 +758,7 @@ ath12k_reg_build_regd(struct ath12k_base *ab,
 			 */
 			flags = NL80211_RRF_AUTO_BW |
 				ath12k_get_bw_reg_flags(reg_info->max_bw_5g);
-			ath12k_reg_update_freq_range(&ab->reg_freq_5ghz, reg_rule);
+			ath12k_reg_update_freq_range(&pdev->reg_freq_5ghz, reg_rule);
 		} else if (reg_info->is_ext_reg_event && reg_6ghz_number &&
 			   (k < reg_6ghz_number)) {
 			reg_rule = reg_rule_6ghz + k++;
@@ -752,7 +767,7 @@ ath12k_reg_build_regd(struct ath12k_base *ab,
 				ath12k_get_bw_reg_flags(max_bw_6ghz);
 			if (reg_rule->psd_flag)
 				flags |= NL80211_RRF_PSD;
-			ath12k_reg_update_freq_range(&ab->reg_freq_6ghz, reg_rule);
+			ath12k_reg_update_freq_range(&pdev->reg_freq_6ghz, reg_rule);
 		} else {
 			break;
 		}

base-commit: 9f0fe5ad0c9af369400bb87143bc936ebb741391
-- 
2.56.0

Re: [PATCH ath-current] wifi: ath12k: fix lost 5 GHz range by tracking reg ranges per radio

[Baochen Qiang]

On 10/27/2026 9:59 AM, Ahmed Essam wrote:
> ath12k_reg_build_regd() records the frequency span covered by the
> received reg rules in ab->reg_freq_{2,5,6}ghz. Those fields live in
> struct ath12k_base, but firmware sends WMI_REG_CHAN_LIST_CC_EXT per
> radio, and ath12k_regd_update() uses them to compute the frequency
> range of a single radio (ar->freq_range). This causes two problems.
> 
> First, ath12k_regd_update() cannot tell which bands a radio received
> rules for, so it uses ar->supports_6ghz as a proxy: the 5 GHz range is
> skipped for any radio that supports 6 GHz. That is only valid for
> split-pdev devices. On single-pdev devices such as WCN7850 one radio
> covers 2 GHz, 5 GHz and 6 GHz. When firmware switches to a country
> without 6 GHz rules, for example after an 11d update to CN or EG,
> ar->freq_range collapses to 2402-2482 MHz and
> ath12k_reg_update_chan_list() drops every 5 GHz channel from the list
> sent to firmware. From then on firmware no longer scans 5 GHz, a
> 5 GHz-only scan request fails ("received scan start failure event"),
> and 5 GHz networks disappear from scan results, typically shortly after
> boot. They stay gone until the driver is reloaded or firmware moves to
> a country that has 6 GHz rules.
> 
> Second, by code inspection, build_regd() resets all three per-device
> ranges on every event, so on multi-radio devices an event for one radio
> can wipe the range of another radio whose regd_update_work has not run
> yet, silently dropping a band.
> 
> Move reg_freq_{2,5,6}ghz into struct ath12k_pdev and fill them for the
> radio identified by reg_info->phy_id. In ath12k_regd_update(), include
> a band only if this radio registered that band and received reg rules
> for it, instead of guessing from ar->supports_6ghz. Checking the
> registered band is needed because a radio can receive rules for bands
> it does not operate on, e.g. the 6 GHz radio of a split-pdev device.
> 
> Also fix the reg_cap lookup for single-pdev devices: pdev->cap.band[]
> is indexed by enum nl80211_band, but was indexed with the
> WMI_HOST_WLAN_*_CAP bit flags, so the 2 GHz lookup used the 5 GHz
> entry and the 5 GHz lookup used the unset 60 GHz entry. Refresh
> reg_cap for the 6 GHz band as well, as is done for 2 GHz and 5 GHz.
> 
> With ATH12K_DBG_MAC enabled on WCN7850 and the firmware switching to
> EG, the range before this change is:
> 
>   mac pdev 0 freq limit updated. New range 2402->2482 MHz
> 
> and after it:
> 
>   mac pdev 0 freq limit updated. New range 2402->2482 MHz
>   mac pdev 0 freq limit updated. New range 2402->5330 MHz
> 
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
> 
> Fixes: 657b0c72c4ad ("wifi: ath12k: Fix frequency range in driver")
> Fixes: 13324cecbb2c ("wifi: ath12k: Update frequency range if reg rules changes")
> Fixes: 0d777aa2ca77 ("wifi: ath12k: fix mac pdev frequency range update")
> Cc: stable@vger.kernel.org
> Reported-by: Shenghan Gao <gsh20040816@gmail.com>
> Closes: https://lore.kernel.org/all/20260715065218.41232-1-gsh20040816@gmail.com/
> Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
> Assisted-by: Claude:claude-opus-5-5 sparse
> Signed-off-by: Ahmed Essam <mrmrmidoessam@gmail.com>

Ah, I have an almost-identical fix pending internal review, but I think yours is better.
Thanks.

Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>

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

[Baochen Qiang]

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
> 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];

seems we should also refresh reg_cap for single-pdev case 6 GHz band?

>  		}
>  
> 
> base-commit: a1a21995c2e1cc2ca6b2226cfe4f5f018370182a