[PATCH v2 0/2] wifi: ath12k: Fix 5GHz issues on WCN7850

[PATCH v2 0/2] wifi: ath12k: Fix 5GHz issues on WCN7850

[Saikiran]

This series addresses two critical issues affecting 5GHz WiFi functionality
on WCN7850 devices, particularly on the Lenovo Yoga Slim 7x.

Changes in v2:
- Patch 1: Simplified approach - remove frequency range filtering entirely
  instead of trying to work around race conditions. Testing confirmed the
  filtering is fundamentally incompatible with single-phy devices.
- Patch 2: Refined based on maintainer feedback - only reset stats buffer
  when pdev list is empty (not on request failure). Improved commit message
  to explain why reset is needed even with empty pdev list.
- Dropped 3 patches from v1 that were either unnecessary or already fixed
  upstream.

The first patch fixes the primary issue where all 5GHz channels were being
filtered out, making 5GHz completely unusable. The second patch addresses
a firmware stats buffer leak that could cause communication failures during
scanning operations.

Both patches have been tested on WCN7850 hw2.0 PCI with firmware
WLAN.HMT.1.1.c5-00302 on the Lenovo Yoga Slim 7x.

v1: https://lore.kernel.org/ath12k/20260123155750.6007-1-bjsaikiran@gmail.com/

Saikiran (2):
  wifi: ath12k: Remove frequency range filtering for single-phy devices
  wifi: ath12k: Fix firmware stats leak when pdev list is empty

 drivers/net/wireless/ath/ath12k/mac.c |  1 +
 drivers/net/wireless/ath/ath12k/reg.c | 13 -------------
 2 files changed, 1 insertion(+), 13 deletions(-)

-- 
2.51.0

[PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices

[Saikiran]

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,
the freq_range is set to cover the entire supported spectrum, but the
filtering logic incorrectly restricts channels, causing 5GHz to become
completely unusable.

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

Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices

[Baochen Qiang]

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;

Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices

[Saikiran B]

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

Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices

[Baochen Qiang]

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

Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices

[Saikiran B]

Hi Baochen,

1. Here are the MD5 sums from my /lib/firmware/ath12k/WCN7850/hw2.0/
(sourced from linux-firmware 20250901):

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

Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices

[Baochen Qiang]

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

Re: [PATCH v2 1/2] wifi: ath12k: Remove frequency range filtering for single-phy devices

[Saikiran B]

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

[PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Saikiran]

The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
after using ath12k_mac_get_fw_stats().

In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
but the pdev stats list is empty, the function exits without calling
ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
may have populated other stats lists (vdevs, beacons, etc.) in the
ar->fw_stats structure.

Without resetting the stats buffer, this data accumulates across multiple
calls, eventually causing the stats buffer to overflow and leading to
firmware communication failures (error -71/EPROTO) during subsequent
operations.

The issue manifests during 5GHz scanning which triggers multiple TX power
queries. Symptoms include:
- "failed to pull fw stats: -71" errors in dmesg
- 5GHz networks not detected despite hardware support
- 2.4GHz networks work normally

Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
ensuring the stats buffer is properly cleaned up even when only partial
stats data is received from firmware.

Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
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/mac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index e0e49f782bf8..6e35c3ee9864 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
 					struct ath12k_fw_stats_pdev, list);
 	if (!pdev) {
 		spin_unlock_bh(&ar->data_lock);
+		ath12k_fw_stats_reset(ar);
 		goto err_fallback;
 	}
 
-- 
2.51.0

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Baochen Qiang]

On 1/26/2026 5:52 PM, Saikiran wrote:
> The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
> to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
> after using ath12k_mac_get_fw_stats().
> 
> In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
> but the pdev stats list is empty, the function exits without calling
> ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
> may have populated other stats lists (vdevs, beacons, etc.) in the

'may' is not enough, we need to be 100% sure whether other stats are populated. This is
critical for us to find the root cause.

> ar->fw_stats structure.
> 
> Without resetting the stats buffer, this data accumulates across multiple
> calls, eventually causing the stats buffer to overflow and leading to
> firmware communication failures (error -71/EPROTO) during subsequent
> operations.
> 
> The issue manifests during 5GHz scanning which triggers multiple TX power
> queries. Symptoms include:
> - "failed to pull fw stats: -71" errors in dmesg

still, can you please check the logs to see at which exact place is this printed?

> - 5GHz networks not detected despite hardware support
> - 2.4GHz networks work normally
> 
> Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
> ensuring the stats buffer is properly cleaned up even when only partial
> stats data is received from firmware.
> 
> Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
> Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
> 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/mac.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> index e0e49f782bf8..6e35c3ee9864 100644
> --- a/drivers/net/wireless/ath/ath12k/mac.c
> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
>  					struct ath12k_fw_stats_pdev, list);
>  	if (!pdev) {
>  		spin_unlock_bh(&ar->data_lock);
> +		ath12k_fw_stats_reset(ar);
>  		goto err_fallback;
>  	}
>  

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Saikiran B]

Hi Baochen,

Regarding your questions:

"Are other stats populated?"

Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
firmware response was received and valid WMI events were processed.
The firmware response to WMI_REQUEST_PDEV_STAT typically includes
multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
"pdev stats" list ends up empty (e.g., due to specific filtering or
availability), the firmware should have populated other lists (like
vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
these valid entries leak and accumulate.

"Where exactly is -71 (EPROTO) printed?"

The log "failed to pull fw stats: -71" is printed in
ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
where it is returned when buffer validation checks fail (e.g., if (len
< sizeof(*src))). This failure suggests that the accumulated state or
memory corruption from the leak eventually causes the parser to fail
on subsequent events.

So, fixing the leak is necessary for correctness regardless of the
specific side-effect error code.

Thanks & Regards,
Saikiran

On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
<baochen.qiang@oss.qualcomm.com> wrote:
>
>
>
> On 1/26/2026 5:52 PM, Saikiran wrote:
> > The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
> > to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
> > after using ath12k_mac_get_fw_stats().
> >
> > In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
> > but the pdev stats list is empty, the function exits without calling
> > ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
> > may have populated other stats lists (vdevs, beacons, etc.) in the
>
> 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
> critical for us to find the root cause.
>
> > ar->fw_stats structure.
> >
> > Without resetting the stats buffer, this data accumulates across multiple
> > calls, eventually causing the stats buffer to overflow and leading to
> > firmware communication failures (error -71/EPROTO) during subsequent
> > operations.
> >
> > The issue manifests during 5GHz scanning which triggers multiple TX power
> > queries. Symptoms include:
> > - "failed to pull fw stats: -71" errors in dmesg
>
> still, can you please check the logs to see at which exact place is this printed?
>
> > - 5GHz networks not detected despite hardware support
> > - 2.4GHz networks work normally
> >
> > Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
> > ensuring the stats buffer is properly cleaned up even when only partial
> > stats data is received from firmware.
> >
> > Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
> > Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
> > 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/mac.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> > index e0e49f782bf8..6e35c3ee9864 100644
> > --- a/drivers/net/wireless/ath/ath12k/mac.c
> > +++ b/drivers/net/wireless/ath/ath12k/mac.c
> > @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
> >                                       struct ath12k_fw_stats_pdev, list);
> >       if (!pdev) {
> >               spin_unlock_bh(&ar->data_lock);
> > +             ath12k_fw_stats_reset(ar);
> >               goto err_fallback;
> >       }
> >
>

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Saikiran B]

I have analyzed the logs and code flow in depth to provide more
definitive answers for your questions.

The log entries showing the failure are:
[  563.574076] ath12k_pci 0004:01:00.0: failed to pull fw stats: -71
[  564.575896] ath12k_pci 0004:01:00.0: time out while waiting for get fw stats

1. Why are other stats populated?
The "failed to pull fw stats: -71" error is not the initial failure
but a symptom that appears after repeated operations. The leak happens
during *successful* calls prior to this error.

Code flow proving the leak:
- ath12k_mac_get_fw_stats() sends WMI_REQUEST_PDEV_STAT.
- Firmware responds. ath12k_update_stats_event() parses the response.
- ath12k_wmi_fw_stats_process() is called, which splices 'vdevs' and
'beacon' stats into ar->fw_stats.vdevs/bcn.
- ath12k_mac_get_fw_stats() returns 0 (Success).
- In ath12k_mac_op_get_txpower(), the check `if (!pdev)` fails if the
pdev-specific list is empty (but vdev list is NOT empty).
- The function exits via `err_fallback` WITHOUT calling ath12k_fw_stats_reset().
- Result: The 'vdev' and 'beacon' stats that were spliced into
ar->fw_stats remain there, leaking memory and accumulating with every
call.

2. Exact place where -71 is printed:
The error "failed to pull fw stats: -71" is printed in
[ath12k_update_stats_event()](drivers/net/wireless/ath/ath12k/wmi.c).
It corresponds to "ret = ath12k_wmi_pull_fw_stats()" returning -EPROTO.
This propagates from
[ath12k_wmi_tlv_fw_stats_data_parse()](drivers/net/wireless/ath/ath12k/wmi.c),
when buffer validation checks (like `len < sizeof(*src)`) fail.

Conclusion:
The fix in my patch (resetting stats when `!pdev`) is critical because
it ensures that the accumulated 'vdev' and 'beacon' stats are freed
even when the 'pdev' list ends up empty.

Let me know if you need anything else.

Thanks & Regards,
Saikiran

On Tue, Jan 27, 2026 at 9:47 AM Saikiran B <bjsaikiran@gmail.com> wrote:
>
> Hi Baochen,
>
> Regarding your questions:
>
> "Are other stats populated?"
>
> Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
> firmware response was received and valid WMI events were processed.
> The firmware response to WMI_REQUEST_PDEV_STAT typically includes
> multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
> "pdev stats" list ends up empty (e.g., due to specific filtering or
> availability), the firmware should have populated other lists (like
> vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
> these valid entries leak and accumulate.
>
> "Where exactly is -71 (EPROTO) printed?"
>
> The log "failed to pull fw stats: -71" is printed in
> ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
> code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
> where it is returned when buffer validation checks fail (e.g., if (len
> < sizeof(*src))). This failure suggests that the accumulated state or
> memory corruption from the leak eventually causes the parser to fail
> on subsequent events.
>
> So, fixing the leak is necessary for correctness regardless of the
> specific side-effect error code.
>
> Thanks & Regards,
> Saikiran
>
> On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
> >
> >
> >
> > On 1/26/2026 5:52 PM, Saikiran wrote:
> > > The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
> > > to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
> > > after using ath12k_mac_get_fw_stats().
> > >
> > > In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
> > > but the pdev stats list is empty, the function exits without calling
> > > ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
> > > may have populated other stats lists (vdevs, beacons, etc.) in the
> >
> > 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
> > critical for us to find the root cause.
> >
> > > ar->fw_stats structure.
> > >
> > > Without resetting the stats buffer, this data accumulates across multiple
> > > calls, eventually causing the stats buffer to overflow and leading to
> > > firmware communication failures (error -71/EPROTO) during subsequent
> > > operations.
> > >
> > > The issue manifests during 5GHz scanning which triggers multiple TX power
> > > queries. Symptoms include:
> > > - "failed to pull fw stats: -71" errors in dmesg
> >
> > still, can you please check the logs to see at which exact place is this printed?
> >
> > > - 5GHz networks not detected despite hardware support
> > > - 2.4GHz networks work normally
> > >
> > > Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
> > > ensuring the stats buffer is properly cleaned up even when only partial
> > > stats data is received from firmware.
> > >
> > > Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
> > > Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
> > > 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/mac.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> > > index e0e49f782bf8..6e35c3ee9864 100644
> > > --- a/drivers/net/wireless/ath/ath12k/mac.c
> > > +++ b/drivers/net/wireless/ath/ath12k/mac.c
> > > @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
> > >                                       struct ath12k_fw_stats_pdev, list);
> > >       if (!pdev) {
> > >               spin_unlock_bh(&ar->data_lock);
> > > +             ath12k_fw_stats_reset(ar);
> > >               goto err_fallback;
> > >       }
> > >
> >

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Baochen Qiang]

On 1/27/2026 12:40 PM, Saikiran B wrote:
> I have analyzed the logs and code flow in depth to provide more
> definitive answers for your questions.
> 
> The log entries showing the failure are:
> [  563.574076] ath12k_pci 0004:01:00.0: failed to pull fw stats: -71
> [  564.575896] ath12k_pci 0004:01:00.0: time out while waiting for get fw stats
> 
> 1. Why are other stats populated?
> The "failed to pull fw stats: -71" error is not the initial failure
> but a symptom that appears after repeated operations. The leak happens
> during *successful* calls prior to this error.
> 
> Code flow proving the leak:
> - ath12k_mac_get_fw_stats() sends WMI_REQUEST_PDEV_STAT.
> - Firmware responds. ath12k_update_stats_event() parses the response.
> - ath12k_wmi_fw_stats_process() is called, which splices 'vdevs' and
> 'beacon' stats into ar->fw_stats.vdevs/bcn.
> - ath12k_mac_get_fw_stats() returns 0 (Success).
> - In ath12k_mac_op_get_txpower(), the check `if (!pdev)` fails if the
> pdev-specific list is empty (but vdev list is NOT empty).
> - The function exits via `err_fallback` WITHOUT calling ath12k_fw_stats_reset().
> - Result: The 'vdev' and 'beacon' stats that were spliced into
> ar->fw_stats remain there, leaking memory and accumulating with every
> call.
> 
> 2. Exact place where -71 is printed:
> The error "failed to pull fw stats: -71" is printed in
> [ath12k_update_stats_event()](drivers/net/wireless/ath/ath12k/wmi.c).
> It corresponds to "ret = ath12k_wmi_pull_fw_stats()" returning -EPROTO.
> This propagates from
> [ath12k_wmi_tlv_fw_stats_data_parse()](drivers/net/wireless/ath/ath12k/wmi.c),
> when buffer validation checks (like `len < sizeof(*src)`) fail.
> 
> Conclusion:
> The fix in my patch (resetting stats when `!pdev`) is critical because
> it ensures that the accumulated 'vdev' and 'beacon' stats are freed
> even when the 'pdev' list ends up empty.
> 
> Let me know if you need anything else.

can you please try below to see if it can fix your issue?

https://lore.kernel.org/r/20260129-ath12k-fw-stats-fixes-v1-0-55d66064f4d5@oss.qualcomm.com

> 
> Thanks & Regards,
> Saikiran
> 
> On Tue, Jan 27, 2026 at 9:47 AM Saikiran B <bjsaikiran@gmail.com> wrote:
>>
>> Hi Baochen,
>>
>> Regarding your questions:
>>
>> "Are other stats populated?"
>>
>> Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
>> firmware response was received and valid WMI events were processed.
>> The firmware response to WMI_REQUEST_PDEV_STAT typically includes
>> multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
>> "pdev stats" list ends up empty (e.g., due to specific filtering or
>> availability), the firmware should have populated other lists (like
>> vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
>> these valid entries leak and accumulate.
>>
>> "Where exactly is -71 (EPROTO) printed?"
>>
>> The log "failed to pull fw stats: -71" is printed in
>> ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
>> code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
>> where it is returned when buffer validation checks fail (e.g., if (len
>> < sizeof(*src))). This failure suggests that the accumulated state or
>> memory corruption from the leak eventually causes the parser to fail
>> on subsequent events.
>>
>> So, fixing the leak is necessary for correctness regardless of the
>> specific side-effect error code.
>>
>> Thanks & Regards,
>> Saikiran
>>
>> On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
>> <baochen.qiang@oss.qualcomm.com> wrote:
>>>
>>>
>>>
>>> On 1/26/2026 5:52 PM, Saikiran wrote:
>>>> The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
>>>> to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
>>>> after using ath12k_mac_get_fw_stats().
>>>>
>>>> In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
>>>> but the pdev stats list is empty, the function exits without calling
>>>> ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
>>>> may have populated other stats lists (vdevs, beacons, etc.) in the
>>>
>>> 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
>>> critical for us to find the root cause.
>>>
>>>> ar->fw_stats structure.
>>>>
>>>> Without resetting the stats buffer, this data accumulates across multiple
>>>> calls, eventually causing the stats buffer to overflow and leading to
>>>> firmware communication failures (error -71/EPROTO) during subsequent
>>>> operations.
>>>>
>>>> The issue manifests during 5GHz scanning which triggers multiple TX power
>>>> queries. Symptoms include:
>>>> - "failed to pull fw stats: -71" errors in dmesg
>>>
>>> still, can you please check the logs to see at which exact place is this printed?
>>>
>>>> - 5GHz networks not detected despite hardware support
>>>> - 2.4GHz networks work normally
>>>>
>>>> Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
>>>> ensuring the stats buffer is properly cleaned up even when only partial
>>>> stats data is received from firmware.
>>>>
>>>> Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
>>>> Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
>>>> 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/mac.c | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
>>>> index e0e49f782bf8..6e35c3ee9864 100644
>>>> --- a/drivers/net/wireless/ath/ath12k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath12k/mac.c
>>>> @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
>>>>                                       struct ath12k_fw_stats_pdev, list);
>>>>       if (!pdev) {
>>>>               spin_unlock_bh(&ar->data_lock);
>>>> +             ath12k_fw_stats_reset(ar);
>>>>               goto err_fallback;
>>>>       }
>>>>
>>>

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Saikiran B]

On Thu, Jan 29, 2026 at 7:57 AM Baochen Qiang
<baochen.qiang@oss.qualcomm.com> wrote:
>
>
>
> On 1/27/2026 12:40 PM, Saikiran B wrote:
> > I have analyzed the logs and code flow in depth to provide more
> > definitive answers for your questions.
> >
> > The log entries showing the failure are:
> > [  563.574076] ath12k_pci 0004:01:00.0: failed to pull fw stats: -71
> > [  564.575896] ath12k_pci 0004:01:00.0: time out while waiting for get fw stats
> >
> > 1. Why are other stats populated?
> > The "failed to pull fw stats: -71" error is not the initial failure
> > but a symptom that appears after repeated operations. The leak happens
> > during *successful* calls prior to this error.
> >
> > Code flow proving the leak:
> > - ath12k_mac_get_fw_stats() sends WMI_REQUEST_PDEV_STAT.
> > - Firmware responds. ath12k_update_stats_event() parses the response.
> > - ath12k_wmi_fw_stats_process() is called, which splices 'vdevs' and
> > 'beacon' stats into ar->fw_stats.vdevs/bcn.
> > - ath12k_mac_get_fw_stats() returns 0 (Success).
> > - In ath12k_mac_op_get_txpower(), the check `if (!pdev)` fails if the
> > pdev-specific list is empty (but vdev list is NOT empty).
> > - The function exits via `err_fallback` WITHOUT calling ath12k_fw_stats_reset().
> > - Result: The 'vdev' and 'beacon' stats that were spliced into
> > ar->fw_stats remain there, leaking memory and accumulating with every
> > call.
> >
> > 2. Exact place where -71 is printed:
> > The error "failed to pull fw stats: -71" is printed in
> > [ath12k_update_stats_event()](drivers/net/wireless/ath/ath12k/wmi.c).
> > It corresponds to "ret = ath12k_wmi_pull_fw_stats()" returning -EPROTO.
> > This propagates from
> > [ath12k_wmi_tlv_fw_stats_data_parse()](drivers/net/wireless/ath/ath12k/wmi.c),
> > when buffer validation checks (like `len < sizeof(*src)`) fail.
> >
> > Conclusion:
> > The fix in my patch (resetting stats when `!pdev`) is critical because
> > it ensures that the accumulated 'vdev' and 'beacon' stats are freed
> > even when the 'pdev' list ends up empty.
> >
> > Let me know if you need anything else.
>
> can you please try below to see if it can fix your issue?
>
> https://lore.kernel.org/r/20260129-ath12k-fw-stats-fixes-v1-0-55d66064f4d5@oss.qualcomm.com
>
> >
> > Thanks & Regards,
> > Saikiran
> >
> > On Tue, Jan 27, 2026 at 9:47 AM Saikiran B <bjsaikiran@gmail.com> wrote:
> >>
> >> Hi Baochen,
> >>
> >> Regarding your questions:
> >>
> >> "Are other stats populated?"
> >>
> >> Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
> >> firmware response was received and valid WMI events were processed.
> >> The firmware response to WMI_REQUEST_PDEV_STAT typically includes
> >> multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
> >> "pdev stats" list ends up empty (e.g., due to specific filtering or
> >> availability), the firmware should have populated other lists (like
> >> vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
> >> these valid entries leak and accumulate.
> >>
> >> "Where exactly is -71 (EPROTO) printed?"
> >>
> >> The log "failed to pull fw stats: -71" is printed in
> >> ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
> >> code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
> >> where it is returned when buffer validation checks fail (e.g., if (len
> >> < sizeof(*src))). This failure suggests that the accumulated state or
> >> memory corruption from the leak eventually causes the parser to fail
> >> on subsequent events.
> >>
> >> So, fixing the leak is necessary for correctness regardless of the
> >> specific side-effect error code.
> >>
> >> Thanks & Regards,
> >> Saikiran
> >>
> >> On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
> >> <baochen.qiang@oss.qualcomm.com> wrote:
> >>>
> >>>
> >>>
> >>> On 1/26/2026 5:52 PM, Saikiran wrote:
> >>>> The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
> >>>> to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
> >>>> after using ath12k_mac_get_fw_stats().
> >>>>
> >>>> In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
> >>>> but the pdev stats list is empty, the function exits without calling
> >>>> ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
> >>>> may have populated other stats lists (vdevs, beacons, etc.) in the
> >>>
> >>> 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
> >>> critical for us to find the root cause.
> >>>
> >>>> ar->fw_stats structure.
> >>>>
> >>>> Without resetting the stats buffer, this data accumulates across multiple
> >>>> calls, eventually causing the stats buffer to overflow and leading to
> >>>> firmware communication failures (error -71/EPROTO) during subsequent
> >>>> operations.
> >>>>
> >>>> The issue manifests during 5GHz scanning which triggers multiple TX power
> >>>> queries. Symptoms include:
> >>>> - "failed to pull fw stats: -71" errors in dmesg
> >>>
> >>> still, can you please check the logs to see at which exact place is this printed?
> >>>
> >>>> - 5GHz networks not detected despite hardware support
> >>>> - 2.4GHz networks work normally
> >>>>
> >>>> Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
> >>>> ensuring the stats buffer is properly cleaned up even when only partial
> >>>> stats data is received from firmware.
> >>>>
> >>>> Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
> >>>> Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
> >>>> 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/mac.c | 1 +
> >>>>  1 file changed, 1 insertion(+)
> >>>>
> >>>> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> >>>> index e0e49f782bf8..6e35c3ee9864 100644
> >>>> --- a/drivers/net/wireless/ath/ath12k/mac.c
> >>>> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> >>>> @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
> >>>>                                       struct ath12k_fw_stats_pdev, list);
> >>>>       if (!pdev) {
> >>>>               spin_unlock_bh(&ar->data_lock);
> >>>> +             ath12k_fw_stats_reset(ar);
> >>>>               goto err_fallback;
> >>>>       }
> >>>>
> >>>
>

Hi Baochen,

I tried applying your patches on top of v6.19-rc7 (which is the latest
mainline release candidate I'm testing on), but I ran into build
issues because some of the dependencies seem missing.

Specifically:
Patch 2 ("wifi: ath12k: fix station lookup failure when disconnecting
from AP") uses `ath12k_link_sta_find_by_addr()`, which does not exist
in my tree. It seems your patches are based on a different tree
(ath-next?) that has newer changes not yet in the mainline.

Could you please point me to the specific git repo/branch you are
using? I can try to build and test on that baseline to be sure.

Regarding the firmware stats issue:
I verified the firmware files match the latest available (MD5 sums
matched), yet the "-71" errors and memory leak persist on my device
without fixes.

I successfully applied the logic from your Patch 1 manually (since
[ath12k_mac_get_target_pdev_id](cci:1://file:///home/saikiran/linux/kernel/x1e/x1e/drivers/net/wireless/ath/ath12k/mac.c:989:0-1008:1)
exists), but I haven't fully validated if it alone resolves the leak
in all scenarios.

However, the fix I proposed in my v2 patch (resetting stats when pdev
list is empty) definitely stops the leak mechanism by ensuring cleanup
happens even when the firmware returns partial stats (which seems to
be the trigger condition).

I'll wait for your pointer to the base tree to do a proper test of your series.

Thanks & Regards,
Saikiran

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Baochen Qiang]

On 1/29/2026 10:06 PM, Saikiran B wrote:
> On Thu, Jan 29, 2026 at 7:57 AM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 1/27/2026 12:40 PM, Saikiran B wrote:
>>> I have analyzed the logs and code flow in depth to provide more
>>> definitive answers for your questions.
>>>
>>> The log entries showing the failure are:
>>> [  563.574076] ath12k_pci 0004:01:00.0: failed to pull fw stats: -71
>>> [  564.575896] ath12k_pci 0004:01:00.0: time out while waiting for get fw stats
>>>
>>> 1. Why are other stats populated?
>>> The "failed to pull fw stats: -71" error is not the initial failure
>>> but a symptom that appears after repeated operations. The leak happens
>>> during *successful* calls prior to this error.
>>>
>>> Code flow proving the leak:
>>> - ath12k_mac_get_fw_stats() sends WMI_REQUEST_PDEV_STAT.
>>> - Firmware responds. ath12k_update_stats_event() parses the response.
>>> - ath12k_wmi_fw_stats_process() is called, which splices 'vdevs' and
>>> 'beacon' stats into ar->fw_stats.vdevs/bcn.
>>> - ath12k_mac_get_fw_stats() returns 0 (Success).
>>> - In ath12k_mac_op_get_txpower(), the check `if (!pdev)` fails if the
>>> pdev-specific list is empty (but vdev list is NOT empty).
>>> - The function exits via `err_fallback` WITHOUT calling ath12k_fw_stats_reset().
>>> - Result: The 'vdev' and 'beacon' stats that were spliced into
>>> ar->fw_stats remain there, leaking memory and accumulating with every
>>> call.
>>>
>>> 2. Exact place where -71 is printed:
>>> The error "failed to pull fw stats: -71" is printed in
>>> [ath12k_update_stats_event()](drivers/net/wireless/ath/ath12k/wmi.c).
>>> It corresponds to "ret = ath12k_wmi_pull_fw_stats()" returning -EPROTO.
>>> This propagates from
>>> [ath12k_wmi_tlv_fw_stats_data_parse()](drivers/net/wireless/ath/ath12k/wmi.c),
>>> when buffer validation checks (like `len < sizeof(*src)`) fail.
>>>
>>> Conclusion:
>>> The fix in my patch (resetting stats when `!pdev`) is critical because
>>> it ensures that the accumulated 'vdev' and 'beacon' stats are freed
>>> even when the 'pdev' list ends up empty.
>>>
>>> Let me know if you need anything else.
>>
>> can you please try below to see if it can fix your issue?
>>
>> https://lore.kernel.org/r/20260129-ath12k-fw-stats-fixes-v1-0-55d66064f4d5@oss.qualcomm.com
>>
>>>
>>> Thanks & Regards,
>>> Saikiran
>>>
>>> On Tue, Jan 27, 2026 at 9:47 AM Saikiran B <bjsaikiran@gmail.com> wrote:
>>>>
>>>> Hi Baochen,
>>>>
>>>> Regarding your questions:
>>>>
>>>> "Are other stats populated?"
>>>>
>>>> Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
>>>> firmware response was received and valid WMI events were processed.
>>>> The firmware response to WMI_REQUEST_PDEV_STAT typically includes
>>>> multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
>>>> "pdev stats" list ends up empty (e.g., due to specific filtering or
>>>> availability), the firmware should have populated other lists (like
>>>> vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
>>>> these valid entries leak and accumulate.
>>>>
>>>> "Where exactly is -71 (EPROTO) printed?"
>>>>
>>>> The log "failed to pull fw stats: -71" is printed in
>>>> ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
>>>> code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
>>>> where it is returned when buffer validation checks fail (e.g., if (len
>>>> < sizeof(*src))). This failure suggests that the accumulated state or
>>>> memory corruption from the leak eventually causes the parser to fail
>>>> on subsequent events.
>>>>
>>>> So, fixing the leak is necessary for correctness regardless of the
>>>> specific side-effect error code.
>>>>
>>>> Thanks & Regards,
>>>> Saikiran
>>>>
>>>> On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
>>>> <baochen.qiang@oss.qualcomm.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 1/26/2026 5:52 PM, Saikiran wrote:
>>>>>> The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
>>>>>> to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
>>>>>> after using ath12k_mac_get_fw_stats().
>>>>>>
>>>>>> In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
>>>>>> but the pdev stats list is empty, the function exits without calling
>>>>>> ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
>>>>>> may have populated other stats lists (vdevs, beacons, etc.) in the
>>>>>
>>>>> 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
>>>>> critical for us to find the root cause.
>>>>>
>>>>>> ar->fw_stats structure.
>>>>>>
>>>>>> Without resetting the stats buffer, this data accumulates across multiple
>>>>>> calls, eventually causing the stats buffer to overflow and leading to
>>>>>> firmware communication failures (error -71/EPROTO) during subsequent
>>>>>> operations.
>>>>>>
>>>>>> The issue manifests during 5GHz scanning which triggers multiple TX power
>>>>>> queries. Symptoms include:
>>>>>> - "failed to pull fw stats: -71" errors in dmesg
>>>>>
>>>>> still, can you please check the logs to see at which exact place is this printed?
>>>>>
>>>>>> - 5GHz networks not detected despite hardware support
>>>>>> - 2.4GHz networks work normally
>>>>>>
>>>>>> Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
>>>>>> ensuring the stats buffer is properly cleaned up even when only partial
>>>>>> stats data is received from firmware.
>>>>>>
>>>>>> Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
>>>>>> Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
>>>>>> 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/mac.c | 1 +
>>>>>>  1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
>>>>>> index e0e49f782bf8..6e35c3ee9864 100644
>>>>>> --- a/drivers/net/wireless/ath/ath12k/mac.c
>>>>>> +++ b/drivers/net/wireless/ath/ath12k/mac.c
>>>>>> @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
>>>>>>                                       struct ath12k_fw_stats_pdev, list);
>>>>>>       if (!pdev) {
>>>>>>               spin_unlock_bh(&ar->data_lock);
>>>>>> +             ath12k_fw_stats_reset(ar);
>>>>>>               goto err_fallback;
>>>>>>       }
>>>>>>
>>>>>
>>
> 
> Hi Baochen,
> 
> I tried applying your patches on top of v6.19-rc7 (which is the latest
> mainline release candidate I'm testing on), but I ran into build
> issues because some of the dependencies seem missing.
> 
> Specifically:
> Patch 2 ("wifi: ath12k: fix station lookup failure when disconnecting
> from AP") uses `ath12k_link_sta_find_by_addr()`, which does not exist
> in my tree. It seems your patches are based on a different tree
> (ath-next?) that has newer changes not yet in the mainline.
> 
> Could you please point me to the specific git repo/branch you are
> using? I can try to build and test on that baseline to be sure.

My bad. Please try the latest ath tree:

https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/

the base commit is ath-202601271544 tag.

> 
> Regarding the firmware stats issue:
> I verified the firmware files match the latest available (MD5 sums
> matched), yet the "-71" errors and memory leak persist on my device
> without fixes.
> 
> I successfully applied the logic from your Patch 1 manually (since
> [ath12k_mac_get_target_pdev_id](cci:1://file:///home/saikiran/linux/kernel/x1e/x1e/drivers/net/wireless/ath/ath12k/mac.c:989:0-1008:1)
> exists), but I haven't fully validated if it alone resolves the leak
> in all scenarios.
> 
> However, the fix I proposed in my v2 patch (resetting stats when pdev
> list is empty) definitely stops the leak mechanism by ensuring cleanup
> happens even when the firmware returns partial stats (which seems to
> be the trigger condition).
> 
> I'll wait for your pointer to the base tree to do a proper test of your series.
> 
> Thanks & Regards,
> Saikiran

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Saikiran B]

On Fri, Jan 30, 2026 at 7:39 AM Baochen Qiang
<baochen.qiang@oss.qualcomm.com> wrote:
>
>
>
> On 1/29/2026 10:06 PM, Saikiran B wrote:
> > On Thu, Jan 29, 2026 at 7:57 AM Baochen Qiang
> > <baochen.qiang@oss.qualcomm.com> wrote:
> >>
> >>
> >>
> >> On 1/27/2026 12:40 PM, Saikiran B wrote:
> >>> I have analyzed the logs and code flow in depth to provide more
> >>> definitive answers for your questions.
> >>>
> >>> The log entries showing the failure are:
> >>> [  563.574076] ath12k_pci 0004:01:00.0: failed to pull fw stats: -71
> >>> [  564.575896] ath12k_pci 0004:01:00.0: time out while waiting for get fw stats
> >>>
> >>> 1. Why are other stats populated?
> >>> The "failed to pull fw stats: -71" error is not the initial failure
> >>> but a symptom that appears after repeated operations. The leak happens
> >>> during *successful* calls prior to this error.
> >>>
> >>> Code flow proving the leak:
> >>> - ath12k_mac_get_fw_stats() sends WMI_REQUEST_PDEV_STAT.
> >>> - Firmware responds. ath12k_update_stats_event() parses the response.
> >>> - ath12k_wmi_fw_stats_process() is called, which splices 'vdevs' and
> >>> 'beacon' stats into ar->fw_stats.vdevs/bcn.
> >>> - ath12k_mac_get_fw_stats() returns 0 (Success).
> >>> - In ath12k_mac_op_get_txpower(), the check `if (!pdev)` fails if the
> >>> pdev-specific list is empty (but vdev list is NOT empty).
> >>> - The function exits via `err_fallback` WITHOUT calling ath12k_fw_stats_reset().
> >>> - Result: The 'vdev' and 'beacon' stats that were spliced into
> >>> ar->fw_stats remain there, leaking memory and accumulating with every
> >>> call.
> >>>
> >>> 2. Exact place where -71 is printed:
> >>> The error "failed to pull fw stats: -71" is printed in
> >>> [ath12k_update_stats_event()](drivers/net/wireless/ath/ath12k/wmi.c).
> >>> It corresponds to "ret = ath12k_wmi_pull_fw_stats()" returning -EPROTO.
> >>> This propagates from
> >>> [ath12k_wmi_tlv_fw_stats_data_parse()](drivers/net/wireless/ath/ath12k/wmi.c),
> >>> when buffer validation checks (like `len < sizeof(*src)`) fail.
> >>>
> >>> Conclusion:
> >>> The fix in my patch (resetting stats when `!pdev`) is critical because
> >>> it ensures that the accumulated 'vdev' and 'beacon' stats are freed
> >>> even when the 'pdev' list ends up empty.
> >>>
> >>> Let me know if you need anything else.
> >>
> >> can you please try below to see if it can fix your issue?
> >>
> >> https://lore.kernel.org/r/20260129-ath12k-fw-stats-fixes-v1-0-55d66064f4d5@oss.qualcomm.com
> >>
> >>>
> >>> Thanks & Regards,
> >>> Saikiran
> >>>
> >>> On Tue, Jan 27, 2026 at 9:47 AM Saikiran B <bjsaikiran@gmail.com> wrote:
> >>>>
> >>>> Hi Baochen,
> >>>>
> >>>> Regarding your questions:
> >>>>
> >>>> "Are other stats populated?"
> >>>>
> >>>> Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
> >>>> firmware response was received and valid WMI events were processed.
> >>>> The firmware response to WMI_REQUEST_PDEV_STAT typically includes
> >>>> multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
> >>>> "pdev stats" list ends up empty (e.g., due to specific filtering or
> >>>> availability), the firmware should have populated other lists (like
> >>>> vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
> >>>> these valid entries leak and accumulate.
> >>>>
> >>>> "Where exactly is -71 (EPROTO) printed?"
> >>>>
> >>>> The log "failed to pull fw stats: -71" is printed in
> >>>> ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
> >>>> code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
> >>>> where it is returned when buffer validation checks fail (e.g., if (len
> >>>> < sizeof(*src))). This failure suggests that the accumulated state or
> >>>> memory corruption from the leak eventually causes the parser to fail
> >>>> on subsequent events.
> >>>>
> >>>> So, fixing the leak is necessary for correctness regardless of the
> >>>> specific side-effect error code.
> >>>>
> >>>> Thanks & Regards,
> >>>> Saikiran
> >>>>
> >>>> On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
> >>>> <baochen.qiang@oss.qualcomm.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 1/26/2026 5:52 PM, Saikiran wrote:
> >>>>>> The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
> >>>>>> to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
> >>>>>> after using ath12k_mac_get_fw_stats().
> >>>>>>
> >>>>>> In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
> >>>>>> but the pdev stats list is empty, the function exits without calling
> >>>>>> ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
> >>>>>> may have populated other stats lists (vdevs, beacons, etc.) in the
> >>>>>
> >>>>> 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
> >>>>> critical for us to find the root cause.
> >>>>>
> >>>>>> ar->fw_stats structure.
> >>>>>>
> >>>>>> Without resetting the stats buffer, this data accumulates across multiple
> >>>>>> calls, eventually causing the stats buffer to overflow and leading to
> >>>>>> firmware communication failures (error -71/EPROTO) during subsequent
> >>>>>> operations.
> >>>>>>
> >>>>>> The issue manifests during 5GHz scanning which triggers multiple TX power
> >>>>>> queries. Symptoms include:
> >>>>>> - "failed to pull fw stats: -71" errors in dmesg
> >>>>>
> >>>>> still, can you please check the logs to see at which exact place is this printed?
> >>>>>
> >>>>>> - 5GHz networks not detected despite hardware support
> >>>>>> - 2.4GHz networks work normally
> >>>>>>
> >>>>>> Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
> >>>>>> ensuring the stats buffer is properly cleaned up even when only partial
> >>>>>> stats data is received from firmware.
> >>>>>>
> >>>>>> Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
> >>>>>> Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
> >>>>>> 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/mac.c | 1 +
> >>>>>>  1 file changed, 1 insertion(+)
> >>>>>>
> >>>>>> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> >>>>>> index e0e49f782bf8..6e35c3ee9864 100644
> >>>>>> --- a/drivers/net/wireless/ath/ath12k/mac.c
> >>>>>> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> >>>>>> @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
> >>>>>>                                       struct ath12k_fw_stats_pdev, list);
> >>>>>>       if (!pdev) {
> >>>>>>               spin_unlock_bh(&ar->data_lock);
> >>>>>> +             ath12k_fw_stats_reset(ar);
> >>>>>>               goto err_fallback;
> >>>>>>       }
> >>>>>>
> >>>>>
> >>
> >
> > Hi Baochen,
> >
> > I tried applying your patches on top of v6.19-rc7 (which is the latest
> > mainline release candidate I'm testing on), but I ran into build
> > issues because some of the dependencies seem missing.
> >
> > Specifically:
> > Patch 2 ("wifi: ath12k: fix station lookup failure when disconnecting
> > from AP") uses `ath12k_link_sta_find_by_addr()`, which does not exist
> > in my tree. It seems your patches are based on a different tree
> > (ath-next?) that has newer changes not yet in the mainline.
> >
> > Could you please point me to the specific git repo/branch you are
> > using? I can try to build and test on that baseline to be sure.
>
> My bad. Please try the latest ath tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/
>
> the base commit is ath-202601271544 tag.
>
> >
> > Regarding the firmware stats issue:
> > I verified the firmware files match the latest available (MD5 sums
> > matched), yet the "-71" errors and memory leak persist on my device
> > without fixes.
> >
> > I successfully applied the logic from your Patch 1 manually (since
> > [ath12k_mac_get_target_pdev_id](cci:1://file:///home/saikiran/linux/kernel/x1e/x1e/drivers/net/wireless/ath/ath12k/mac.c:989:0-1008:1)
> > exists), but I haven't fully validated if it alone resolves the leak
> > in all scenarios.
> >
> > However, the fix I proposed in my v2 patch (resetting stats when pdev
> > list is empty) definitely stops the leak mechanism by ensuring cleanup
> > happens even when the firmware returns partial stats (which seems to
> > be the trigger condition).
> >
> > I'll wait for your pointer to the base tree to do a proper test of your series.
> >
> > Thanks & Regards,
> > Saikiran
>

Hi,

I have merged the tag, applied your patches and I can confirm that the
leak has been fixed.

Thanks & Regards,
Saikiran

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Baochen Qiang]

On 1/30/2026 3:32 PM, Saikiran B wrote:
> On Fri, Jan 30, 2026 at 7:39 AM Baochen Qiang
> <baochen.qiang@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 1/29/2026 10:06 PM, Saikiran B wrote:
>>> On Thu, Jan 29, 2026 at 7:57 AM Baochen Qiang
>>> <baochen.qiang@oss.qualcomm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 1/27/2026 12:40 PM, Saikiran B wrote:
>>>>> I have analyzed the logs and code flow in depth to provide more
>>>>> definitive answers for your questions.
>>>>>
>>>>> The log entries showing the failure are:
>>>>> [  563.574076] ath12k_pci 0004:01:00.0: failed to pull fw stats: -71
>>>>> [  564.575896] ath12k_pci 0004:01:00.0: time out while waiting for get fw stats
>>>>>
>>>>> 1. Why are other stats populated?
>>>>> The "failed to pull fw stats: -71" error is not the initial failure
>>>>> but a symptom that appears after repeated operations. The leak happens
>>>>> during *successful* calls prior to this error.
>>>>>
>>>>> Code flow proving the leak:
>>>>> - ath12k_mac_get_fw_stats() sends WMI_REQUEST_PDEV_STAT.
>>>>> - Firmware responds. ath12k_update_stats_event() parses the response.
>>>>> - ath12k_wmi_fw_stats_process() is called, which splices 'vdevs' and
>>>>> 'beacon' stats into ar->fw_stats.vdevs/bcn.
>>>>> - ath12k_mac_get_fw_stats() returns 0 (Success).
>>>>> - In ath12k_mac_op_get_txpower(), the check `if (!pdev)` fails if the
>>>>> pdev-specific list is empty (but vdev list is NOT empty).
>>>>> - The function exits via `err_fallback` WITHOUT calling ath12k_fw_stats_reset().
>>>>> - Result: The 'vdev' and 'beacon' stats that were spliced into
>>>>> ar->fw_stats remain there, leaking memory and accumulating with every
>>>>> call.
>>>>>
>>>>> 2. Exact place where -71 is printed:
>>>>> The error "failed to pull fw stats: -71" is printed in
>>>>> [ath12k_update_stats_event()](drivers/net/wireless/ath/ath12k/wmi.c).
>>>>> It corresponds to "ret = ath12k_wmi_pull_fw_stats()" returning -EPROTO.
>>>>> This propagates from
>>>>> [ath12k_wmi_tlv_fw_stats_data_parse()](drivers/net/wireless/ath/ath12k/wmi.c),
>>>>> when buffer validation checks (like `len < sizeof(*src)`) fail.
>>>>>
>>>>> Conclusion:
>>>>> The fix in my patch (resetting stats when `!pdev`) is critical because
>>>>> it ensures that the accumulated 'vdev' and 'beacon' stats are freed
>>>>> even when the 'pdev' list ends up empty.
>>>>>
>>>>> Let me know if you need anything else.
>>>>
>>>> can you please try below to see if it can fix your issue?
>>>>
>>>> https://lore.kernel.org/r/20260129-ath12k-fw-stats-fixes-v1-0-55d66064f4d5@oss.qualcomm.com
>>>>
>>>>>
>>>>> Thanks & Regards,
>>>>> Saikiran
>>>>>
>>>>> On Tue, Jan 27, 2026 at 9:47 AM Saikiran B <bjsaikiran@gmail.com> wrote:
>>>>>>
>>>>>> Hi Baochen,
>>>>>>
>>>>>> Regarding your questions:
>>>>>>
>>>>>> "Are other stats populated?"
>>>>>>
>>>>>> Yes. When ath12k_mac_get_fw_stats() returns success (0), it means the
>>>>>> firmware response was received and valid WMI events were processed.
>>>>>> The firmware response to WMI_REQUEST_PDEV_STAT typically includes
>>>>>> multiple stats TLVs (vdev stats, beacon stats, etc.). Even if the
>>>>>> "pdev stats" list ends up empty (e.g., due to specific filtering or
>>>>>> availability), the firmware should have populated other lists (like
>>>>>> vdevs or beacons) in the ar->fw_stats structure. If we don't reset,
>>>>>> these valid entries leak and accumulate.
>>>>>>
>>>>>> "Where exactly is -71 (EPROTO) printed?"
>>>>>>
>>>>>> The log "failed to pull fw stats: -71" is printed in
>>>>>> ath12k_update_stats_event() (wmi.c line 8500 in my tree). This error
>>>>>> code (-EPROTO) propagates from ath12k_wmi_tlv_fw_stats_data_parse(),
>>>>>> where it is returned when buffer validation checks fail (e.g., if (len
>>>>>> < sizeof(*src))). This failure suggests that the accumulated state or
>>>>>> memory corruption from the leak eventually causes the parser to fail
>>>>>> on subsequent events.
>>>>>>
>>>>>> So, fixing the leak is necessary for correctness regardless of the
>>>>>> specific side-effect error code.
>>>>>>
>>>>>> Thanks & Regards,
>>>>>> Saikiran
>>>>>>
>>>>>> On Tue, Jan 27, 2026 at 8:57 AM Baochen Qiang
>>>>>> <baochen.qiang@oss.qualcomm.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/26/2026 5:52 PM, Saikiran wrote:
>>>>>>>> The commits bd6ec8111e65 and 2977567b244f changed firmware stats handling
>>>>>>>> to be caller-driven, requiring explicit ath12k_fw_stats_reset() calls
>>>>>>>> after using ath12k_mac_get_fw_stats().
>>>>>>>>
>>>>>>>> In ath12k_mac_op_get_txpower(), when ath12k_mac_get_fw_stats() succeeds
>>>>>>>> but the pdev stats list is empty, the function exits without calling
>>>>>>>> ath12k_fw_stats_reset(). Even though the pdev list is empty, the firmware
>>>>>>>> may have populated other stats lists (vdevs, beacons, etc.) in the
>>>>>>>
>>>>>>> 'may' is not enough, we need to be 100% sure whether other stats are populated. This is
>>>>>>> critical for us to find the root cause.
>>>>>>>
>>>>>>>> ar->fw_stats structure.
>>>>>>>>
>>>>>>>> Without resetting the stats buffer, this data accumulates across multiple
>>>>>>>> calls, eventually causing the stats buffer to overflow and leading to
>>>>>>>> firmware communication failures (error -71/EPROTO) during subsequent
>>>>>>>> operations.
>>>>>>>>
>>>>>>>> The issue manifests during 5GHz scanning which triggers multiple TX power
>>>>>>>> queries. Symptoms include:
>>>>>>>> - "failed to pull fw stats: -71" errors in dmesg
>>>>>>>
>>>>>>> still, can you please check the logs to see at which exact place is this printed?
>>>>>>>
>>>>>>>> - 5GHz networks not detected despite hardware support
>>>>>>>> - 2.4GHz networks work normally
>>>>>>>>
>>>>>>>> Fix by calling ath12k_fw_stats_reset() when the pdev list is empty,
>>>>>>>> ensuring the stats buffer is properly cleaned up even when only partial
>>>>>>>> stats data is received from firmware.
>>>>>>>>
>>>>>>>> Fixes: bd6ec8111e65 ("wifi: ath12k: Make firmware stats reset caller-driven")
>>>>>>>> Link: https://bugs.launchpad.net/ubuntu-concept/+bug/2138308
>>>>>>>> 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/mac.c | 1 +
>>>>>>>>  1 file changed, 1 insertion(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
>>>>>>>> index e0e49f782bf8..6e35c3ee9864 100644
>>>>>>>> --- a/drivers/net/wireless/ath/ath12k/mac.c
>>>>>>>> +++ b/drivers/net/wireless/ath/ath12k/mac.c
>>>>>>>> @@ -5169,6 +5169,7 @@ static int ath12k_mac_op_get_txpower(struct ieee80211_hw *hw,
>>>>>>>>                                       struct ath12k_fw_stats_pdev, list);
>>>>>>>>       if (!pdev) {
>>>>>>>>               spin_unlock_bh(&ar->data_lock);
>>>>>>>> +             ath12k_fw_stats_reset(ar);
>>>>>>>>               goto err_fallback;
>>>>>>>>       }
>>>>>>>>
>>>>>>>
>>>>
>>>
>>> Hi Baochen,
>>>
>>> I tried applying your patches on top of v6.19-rc7 (which is the latest
>>> mainline release candidate I'm testing on), but I ran into build
>>> issues because some of the dependencies seem missing.
>>>
>>> Specifically:
>>> Patch 2 ("wifi: ath12k: fix station lookup failure when disconnecting
>>> from AP") uses `ath12k_link_sta_find_by_addr()`, which does not exist
>>> in my tree. It seems your patches are based on a different tree
>>> (ath-next?) that has newer changes not yet in the mainline.
>>>
>>> Could you please point me to the specific git repo/branch you are
>>> using? I can try to build and test on that baseline to be sure.
>>
>> My bad. Please try the latest ath tree:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/
>>
>> the base commit is ath-202601271544 tag.
>>
>>>
>>> Regarding the firmware stats issue:
>>> I verified the firmware files match the latest available (MD5 sums
>>> matched), yet the "-71" errors and memory leak persist on my device
>>> without fixes.
>>>
>>> I successfully applied the logic from your Patch 1 manually (since
>>> [ath12k_mac_get_target_pdev_id](cci:1://file:///home/saikiran/linux/kernel/x1e/x1e/drivers/net/wireless/ath/ath12k/mac.c:989:0-1008:1)
>>> exists), but I haven't fully validated if it alone resolves the leak
>>> in all scenarios.
>>>
>>> However, the fix I proposed in my v2 patch (resetting stats when pdev
>>> list is empty) definitely stops the leak mechanism by ensuring cleanup
>>> happens even when the firmware returns partial stats (which seems to
>>> be the trigger condition).
>>>
>>> I'll wait for your pointer to the base tree to do a proper test of your series.
>>>
>>> Thanks & Regards,
>>> Saikiran
>>
> 
> Hi,
> 
> I have merged the tag, applied your patches and I can confirm that the
> leak has been fixed.

Thank you Saikiran for the test!

> 
> Thanks & Regards,
> Saikiran

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Jeff Johnson]

On 1/29/2026 11:32 PM, Saikiran B wrote:
> I have merged the tag, applied your patches and I can confirm that the
> leak has been fixed.

When I apply the patches would you like me to add the following?

Tested-by: Saikiran B <bjsaikiran@gmail.com>

Re: [PATCH v2 2/2] wifi: ath12k: Fix firmware stats leak when pdev list is empty

[Saikiran B]

On Fri, Jan 30, 2026 at 7:57 PM Jeff Johnson
<jeff.johnson@oss.qualcomm.com> wrote:
>
> On 1/29/2026 11:32 PM, Saikiran B wrote:
> > I have merged the tag, applied your patches and I can confirm that the
> > leak has been fixed.
>
> When I apply the patches would you like me to add the following?
>
> Tested-by: Saikiran B <bjsaikiran@gmail.com>

Sure.

Thanks & Regards,
Saikiran