From: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
To: Saikiran B <bjsaikiran@gmail.com>
Cc: ath12k@lists.infradead.org, linux-wireless@vger.kernel.org,
kvalo@kernel.org
Subject: Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices
Date: Tue, 27 Jan 2026 18:21:54 +0800 [thread overview]
Message-ID: <d6910fe4-cd35-4696-9a0e-13904f512ff8@oss.qualcomm.com> (raw)
In-Reply-To: <CAAFDt1sdE3Wpp5CByTZmBk=YnQxFhAwmbC5XpYaqYq0Wdx547A@mail.gmail.com>
On 1/27/2026 4:58 PM, Saikiran B wrote:
> Hi Baochen,
>
> 1. Here are the MD5 sums from my /lib/firmware/ath12k/WCN7850/hw2.0/
> (sourced from linux-firmware 20250901):
this is a bit old. Please try the latest board-2.bin from linux-firmware repo:
commit 1d588f106ceea113c4c650b43d948da5746e704c
Author: Jeff Johnson <jjohnson@qti.qualcomm.com>
Date: Thu Sep 18 11:03:58 2025 -0700
ath12k: WCN7850 hw2.0: update board-2.bin
Signed-off-by: Jeff Johnson <jjohnson@qti.qualcomm.com>
$ md5sum board-2.bin
74878eeb4ea01b8ea6bd19b57c99d702 board-2.bin
>
> 2fa9a691f199b25aafce48967d93c85b amss.bin.zst
> 7cd6eb50e9a6ad98e658a53033214c9e board-2.bin.zst
> 62c117046e52cb78c922635bea177afe m3.bin.zst
> 953ba9719c55664a5d91d99b412caee1 Notice.txt.zst
>
> 2. Logs: I realized CONFIG_ATH12K_DEBUG was disabled in my recent
> build. I am rebuilding the kernel now with the debug mask enabled and
> will provide the verbose logs in a follow-up email once tested.
>
> 3. Regarding the Frequency Logic: While I gather the logs, I'd like to
> highlight that the issue likely persists regardless of the firmware
> behavior.
>
> The freq_range filter assumes ar has a single contiguous range (e.g.,
> start=5150, end=5850). For a Single-PHY device like WCN7850 that
> supports disjoint bands (2.4GHz + 5GHz), a single start/end pair
> cannot correctly represent the capabilities.
>
> If we set it to cover 2.4GHz, it filters 5GHz.
>
> If we set it to cover both (e.g., 2.4GHz to 7GHz), the filter allows
> everything and becomes redundant.
>
> I will get back to you shortly with the logs to confirm the firmware state.
>
> Thanks & Regards,
> Saikiran
>
> On Tue, Jan 27, 2026 at 1:11 PM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 1/27/2026 12:04 PM, Saikiran B wrote:
>>> Hi Baochen,
>>>
>>> I checked the logs again.
>>>
>>> The issue seems to be coming from how
>>> [ath12k_regd_update()](drivers/net/wireless/ath/ath12k/reg.c) handles
>>> frequency range updates for this device. WCN7850 is a single-phy
>>> device (single [ar](drivers/net/wireless/ath/ath12k/mac.c) that
>>> supports both 2.4GHz and 5GHz/6GHz.
>>>
>>> In ath12k_regd_update():
>>>
>>> 1. It updates the range for 2GHz capabilities (sets range to ~2.4GHz).
>>> 2. It then attempts to update for 5GHz capabilities.
>>> 3. Because `ar->supports_6ghz` is true, it uses the 6GHz path logic.
>>> 4. However, `ab->reg_freq_6ghz` appears to be uninitialized/invalid at
>>
>> Hmm, this seems like a known firmware bug. Are you using the latest board-2.bin? please
>> share md5sum of your firmware binaries under /lib/firmware/ath12k/WCN7850/hw2.0
>>
>> If you are using the latest, please help collect verbose ath12k dmesg log:
>>
>> modprobe ath12k debug_mask=0xffffffff
>> modprobe ath12k_wifi7
>>
>>> this stage (possibly due to regulatory init timing or country code
>>> issues, On Lenovo Yoga Slim 7x, SMBIOS does not seem to provide a
>>> valid country code. The driver attempts to set an invalid country code
>>> which the firmware rejects. This inturn triggers this issue. Fixing
>>> SMBIOS parsing/defaults is a separate, complex issue that varies by
>>> vendor.), causing the 5GHz range update to be skipped or invalid.
>>>
>>> [ 11.699027] ath12k_pci 0004:01:00.0: Failed to set the requested
>>> Country regulatory setting
>>> [ 31.111995] ath12k_pci 0004:01:00.0: Failed to set the requested
>>> Country regulatory setting
>>>
>>> As a result, `ar->freq_range` remains effectively set for only the 2.4GHz band.
>>>
>>> When ath12k_reg_update_chan_list() runs:
>>>
>>> It compares 5GHz channels (e.g., 5180 MHz) against a
>>> [freq_range](drivers/net/wireless/ath/ath12k/reg.c) that only covers
>>> 2.4GHz.
>>> Result: `center_freq > end_freq` is TRUE -> Channel is filtered out.
>>>
>>> The filtering logic added in acc152f9be20 works for split-phy topology
>>> where each host ar covers a specific range. For WCN7850, where a
>>> single host ar covers disjoint bands (2.4G + 5G), [freq_range] but
>>> [freq_range](drivers/net/wireless/ath/ath12k/reg.c) (start/end) cannot
>>> represent multiple disjoint bands at the same time.
>>>
>>> Removing this driver-level filter allows the firmware (which knows the
>>> true capabilities) to handle the channel list correctly.
>>>
>>> Thanks & Regards,
>>> Saikiran
>>>
>>> On Tue, Jan 27, 2026 at 8:52 AM Baochen Qiang
>>> <baochen.qiang@oss.qualcomm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 1/26/2026 5:52 PM, Saikiran wrote:
>>>>> The frequency range filtering added in commit acc152f9be20 was designed
>>>>> for split-phy devices where multiple radios with overlapping frequency
>>>>> ranges within the same band are combined into a single wiphy. Each radio
>>>>> in such setups handles only a subset of channels within a band (e.g., two
>>>>> 5GHz radios covering 5GHz-low and 5GHz-high separately).
>>>>>
>>>>> However, this filtering breaks single-phy devices like WCN7850 that use
>>>>> a single radio to handle both 2.4GHz and 5GHz bands. On these devices,
>>>>
>>>> To be accurate, WCN7850 still gets two phys in hardware, it is just in host that we treat
>>>> it as single.
>>>>
>>>>> the freq_range is set to cover the entire supported spectrum, but the
>>>>
>>>> exactly
>>>>
>>>>> filtering logic incorrectly restricts channels, causing 5GHz to become
>>>>> completely unusable.
>>>>
>>>> how? what are the actual values of freq_range when you hit the issue and how are they
>>>> calculated?
>>>>
>>>>>
>>>>> The issue manifests as:
>>>>> - All 5GHz channels filtered out during channel list updates
>>>>> - No 5GHz SSIDs visible in scans
>>>>> - Only 2.4GHz networks functional
>>>>>
>>>>> Remove the frequency range filtering entirely and rely on the firmware
>>>>> to handle frequency restrictions based on actual hardware capabilities.
>>>>> This approach works correctly for both split-phy and single-phy devices,
>>>>> as the firmware has complete knowledge of what the hardware supports.
>>>>>
>>>>> Fixes: acc152f9be20 ("wifi: ath12k: combine channel list for split-phy devices in single-wiphy")
>>>>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302 (Lenovo Yoga Slim 7x)
>>>>> Signed-off-by: Saikiran <bjsaikiran@gmail.com>
>>>>> ---
>>>>> drivers/net/wireless/ath/ath12k/reg.c | 13 -------------
>>>>> 1 file changed, 13 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/wireless/ath/ath12k/reg.c b/drivers/net/wireless/ath/ath12k/reg.c
>>>>> index 7898f6981e5a..48c362a86524 100644
>>>>> --- a/drivers/net/wireless/ath/ath12k/reg.c
>>>>> +++ b/drivers/net/wireless/ath/ath12k/reg.c
>>>>> @@ -153,12 +153,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
>>>>> if (bands[band]->channels[i].flags &
>>>>> IEEE80211_CHAN_DISABLED)
>>>>> continue;
>>>>> - /* Skip Channels that are not in current radio's range */
>>>>> - if (bands[band]->channels[i].center_freq <
>>>>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
>>>>> - bands[band]->channels[i].center_freq >
>>>>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
>>>>> - continue;
>>>>>
>>>>> num_channels++;
>>>>> }
>>>>> @@ -190,13 +184,6 @@ int ath12k_reg_update_chan_list(struct ath12k *ar, bool wait)
>>>>> if (channel->flags & IEEE80211_CHAN_DISABLED)
>>>>> continue;
>>>>>
>>>>> - /* Skip Channels that are not in current radio's range */
>>>>> - if (bands[band]->channels[i].center_freq <
>>>>> - KHZ_TO_MHZ(ar->freq_range.start_freq) ||
>>>>> - bands[band]->channels[i].center_freq >
>>>>> - KHZ_TO_MHZ(ar->freq_range.end_freq))
>>>>> - continue;
>>>>> -
>>>>> /* TODO: Set to true/false based on some condition? */
>>>>> ch->allow_ht = true;
>>>>> ch->allow_vht = true;
>>>>
>>
next prev parent reply other threads:[~2026-01-27 10:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 9:52 [PATCH v2 0/2] wifi: ath12k: Fix 5GHz issues on WCN7850 Saikiran
2026-01-26 9:52 ` [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices Saikiran
2026-01-27 3:22 ` Baochen Qiang
2026-01-27 4:04 ` Saikiran B
2026-01-27 7:41 ` Baochen Qiang
2026-01-27 8:58 ` Saikiran B
2026-01-27 10:21 ` Baochen Qiang [this message]
2026-01-27 19:06 ` Saikiran B
2026-01-26 9:52 ` [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty Saikiran
2026-01-27 3:27 ` Baochen Qiang
2026-01-27 4:17 ` Saikiran B
2026-01-27 4:40 ` Saikiran B
2026-01-29 2:27 ` Baochen Qiang
2026-01-29 14:06 ` Saikiran B
2026-01-30 2:09 ` Baochen Qiang
2026-01-30 7:32 ` Saikiran B
2026-01-30 7:50 ` Baochen Qiang
2026-01-30 14:27 ` Jeff Johnson
2026-01-30 16:45 ` Saikiran B
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d6910fe4-cd35-4696-9a0e-13904f512ff8@oss.qualcomm.com \
--to=baochen.qiang@oss.qualcomm.com \
--cc=ath12k@lists.infradead.org \
--cc=bjsaikiran@gmail.com \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox