[PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices
Saikiran B
bjsaikiran at gmail.com
Tue Jan 27 11:06:26 PST 2026
Hi Baochen,
You were absolutely right.
I manually updated board-2.bin to the latest upstream version (MD5:
74878...), and 5GHz is now working perfectly without any driver
changes.
It seems the linux-firmware package provided by my distro was just old
enough to miss that specific fix.
Next Steps:
I will drop the "Remove frequency range filtering" patch (Patch 1/2)
since the correct firmware resolves the root cause.
Regarding the "Firmware stats leak" (Patch 2/2): I am currently
testing the new firmware without this patch to see if the -71 errors
persist. If the driver still leaks memory on error paths, I will send
this as a standalone patch.
Thanks for pointing out the firmware mismatch!
Thanks & Regards,
Saikiran
On Tue, Jan 27, 2026 at 3:52 PM Baochen Qiang
<baochen.qiang at oss.qualcomm.com> wrote:
>
>
>
> 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 at 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 at 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 at 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 at 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 at 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;
> >>>>
> >>
>
More information about the ath12k
mailing list