* Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
From: Johannes Berg @ 2026-03-02 15:38 UTC (permalink / raw)
To: Ben Greear, linux-wireless; +Cc: Korenblit, Miriam Rachel, linux-mm, Tejun Heo
In-Reply-To: <0de6c8d1-d2fa-44ac-8025-cfcfecd87b02@candelatech.com>
On Mon, 2026-03-02 at 07:26 -0800, Ben Greear wrote:
>
> >
> > Was this with lockdep? If so, it complain about anything?
> >
> > I'm having a hard time seeing why it would deadlock at all when wifi
> > uses schedule_work() and therefore the system_percpu_wq, and
> > __lru_add_drain_all() flushes lru_add_drain_work on mm_percpu_wq, and
> > lru_add_and_bh_lrus_drain() doesn't really _seem_ to do anything related
> > to RTNL etc.?
> >
> > I think we need a real explanation here rather than "if I randomly
> > change this, it no longer appears".
>
> The path where iwlwifi acquires CMA holds rtnl and/or wiphy locks before
> allocating CMA memory, as expected.
>
> And the CMA allocation path attempts to flush the work queues in
> at least some cases.
>
> If there is a work item queued that is trying to grab rtnl and/or wiphy lock
> when CMA attempts to flush, then the flush work cannot complete, so it deadlocks.
>
> Lockdep doesn't warn about this.
It really should, in cases where it can actually happen, I wrote the
code myself for that... Though things have changed since, and the checks
were lost at least once (and re-added), so I suppose it's possible that
they were lost _again_, but the flushing system is far more flexible now
and it's not flushing the same workqueue anyway, so it shouldn't happen.
I stand by what I said before, need to show more precisely what depends
on what, and I'm not going to accept a random kthread into this.
johannes
^ permalink raw reply
* Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
From: Ben Greear @ 2026-03-02 15:26 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Korenblit, Miriam Rachel, linux-mm
In-Reply-To: <3456b2c89f057900b39ce79ea8ca1154c5014e43.camel@sipsolutions.net>
On 3/2/26 00:07, Johannes Berg wrote:
> On Sun, 2026-03-01 at 07:38 -0800, Ben Greear wrote:
>> On 2/27/26 08:31, Ben Greear wrote:
>>> On 2/23/26 14:36, Ben Greear wrote:
>>>> Hello,
>>>>
>>>> I hit a deadlock related to CMA mem allocation attempting to flush all work
>>>> while holding some wifi related mutex, and with a work-queue attempting to process a wifi regdomain
>>>> work item. I really don't see any good way to fix this,
>>>> it would seem that any code that was holding a mutex that could block a work-queue
>>>> cannot safely allocate CMA memory? Hopefully someone else has a better idea.
>>>
>>> I tried using a kthread to do the regulatory domain processing instead of worker item,
>>> and that seems to have solved the problem. If that seems reasonable approach to
>>> wifi stack folks, I can post a patch.
>>
>> The other net/wireless work-item 'disconnect_work' also needs to be moved to the kthread
>> for the same reason....
>
> I don't think we want to use a kthread for this, it doesn't really make
> sense.
>
> Was this with lockdep? If so, it complain about anything?
>
> I'm having a hard time seeing why it would deadlock at all when wifi
> uses schedule_work() and therefore the system_percpu_wq, and
> __lru_add_drain_all() flushes lru_add_drain_work on mm_percpu_wq, and
> lru_add_and_bh_lrus_drain() doesn't really _seem_ to do anything related
> to RTNL etc.?
>
> I think we need a real explanation here rather than "if I randomly
> change this, it no longer appears".
The path where iwlwifi acquires CMA holds rtnl and/or wiphy locks before
allocating CMA memory, as expected.
And the CMA allocation path attempts to flush the work queues in
at least some cases.
If there is a work item queued that is trying to grab rtnl and/or wiphy lock
when CMA attempts to flush, then the flush work cannot complete, so it deadlocks.
Lockdep doesn't warn about this.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: CMA allocation fails with default 128M on X1E80100 (Lenovo 21N1CT01WW) for ath12k
From: Dmitry Baryshkov @ 2026-03-02 13:17 UTC (permalink / raw)
To: Konrad Dybcio
Cc: René Mérou, linux-arm-msm@vger.kernel.org,
linux-wireless@vger.kernel.org, Krzysztof Kozlowski,
Bjorn Andersson
In-Reply-To: <d71ef31a-d7dd-4350-a784-a77e63be96ec@oss.qualcomm.com>
On Mon, Mar 02, 2026 at 12:20:17PM +0100, Konrad Dybcio wrote:
> On 3/2/26 12:19 PM, Konrad Dybcio wrote:
> > On 2/28/26 10:29 AM, René Mérou wrote:
> >> Hi,
> >> I'm experiencing CMA allocation failures with the ath12k WiFi driver on my new Lenovo 21N1CT01WW (Snapdragon X1E80100).
> >>
> >> Error in dmesg
> >> cma: __cma_alloc: reserved: alloc failed, req-size: 257 pages, ret: -16
> >> cma: => 1042 free of 32768 total pages
> >>
> >> System details
> >> Kernel: 6.17.0-8-qcom-x1e (Ubuntu)
> >> Default CMA size: 128M (set by the distribution for this hardware)
> >> WiFi chip: ath12k_pci (Qualcomm WCN685x)
> >>
> >> What I found
> >> With the default 128M CMA, the allocation of 257 pages (~1MB) fails
> >> After increasing CMA to 256M (by adding cma=256M to the kernel command line), the error disappears and WiFi works correctly
> >>
> >> My questions
> >> Is 128M expected to be sufficient for ath12k on this platform?
> >> Could the driver be optimized to need less contiguous memory?
> >> Should the default CMA size be increased to 256M for X1E80100 devices?
> >
> > The default value in the arm64 defconfig is CONFIG_CMA_SIZE_MBYTES=32,
> > although most laptop DTs individually add a 128M zone under /reserved-memory
> >
> > We should probably enlarge this value in either of those places, although I
> > don't know whether changing the defconfig is going to be welcomed..
Can we change DT instead of changing defconfig?
>
> +CC FYI
>
> Konrad
--
With best wishes
Dmitry
^ permalink raw reply
* Re: CMA allocation fails with default 128M on X1E80100 (Lenovo 21N1CT01WW) for ath12k
From: Konrad Dybcio @ 2026-03-02 11:20 UTC (permalink / raw)
To: René Mérou, linux-arm-msm@vger.kernel.org
Cc: linux-wireless@vger.kernel.org, Krzysztof Kozlowski,
Dmitry Baryshkov, Bjorn Andersson
In-Reply-To: <05ff4122-1a8b-4728-81ac-33a7ca542461@oss.qualcomm.com>
On 3/2/26 12:19 PM, Konrad Dybcio wrote:
> On 2/28/26 10:29 AM, René Mérou wrote:
>> Hi,
>> I'm experiencing CMA allocation failures with the ath12k WiFi driver on my new Lenovo 21N1CT01WW (Snapdragon X1E80100).
>>
>> Error in dmesg
>> cma: __cma_alloc: reserved: alloc failed, req-size: 257 pages, ret: -16
>> cma: => 1042 free of 32768 total pages
>>
>> System details
>> Kernel: 6.17.0-8-qcom-x1e (Ubuntu)
>> Default CMA size: 128M (set by the distribution for this hardware)
>> WiFi chip: ath12k_pci (Qualcomm WCN685x)
>>
>> What I found
>> With the default 128M CMA, the allocation of 257 pages (~1MB) fails
>> After increasing CMA to 256M (by adding cma=256M to the kernel command line), the error disappears and WiFi works correctly
>>
>> My questions
>> Is 128M expected to be sufficient for ath12k on this platform?
>> Could the driver be optimized to need less contiguous memory?
>> Should the default CMA size be increased to 256M for X1E80100 devices?
>
> The default value in the arm64 defconfig is CONFIG_CMA_SIZE_MBYTES=32,
> although most laptop DTs individually add a 128M zone under /reserved-memory
>
> We should probably enlarge this value in either of those places, although I
> don't know whether changing the defconfig is going to be welcomed..
+CC FYI
Konrad
^ permalink raw reply
* Re: CMA allocation fails with default 128M on X1E80100 (Lenovo 21N1CT01WW) for ath12k
From: Konrad Dybcio @ 2026-03-02 11:19 UTC (permalink / raw)
To: René Mérou, linux-arm-msm@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <7pJkV7xouk-7S77gIvCwPj5EAAVe0JWdkD5Dc4Q7Y77_gPr5m7jMA2om7AyEN6RKBmEyFbIDJceHFstXFuzPJWPNhqafLXOu2O0uCDZEFcY=@pm.me>
On 2/28/26 10:29 AM, René Mérou wrote:
> Hi,
> I'm experiencing CMA allocation failures with the ath12k WiFi driver on my new Lenovo 21N1CT01WW (Snapdragon X1E80100).
>
> Error in dmesg
> cma: __cma_alloc: reserved: alloc failed, req-size: 257 pages, ret: -16
> cma: => 1042 free of 32768 total pages
>
> System details
> Kernel: 6.17.0-8-qcom-x1e (Ubuntu)
> Default CMA size: 128M (set by the distribution for this hardware)
> WiFi chip: ath12k_pci (Qualcomm WCN685x)
>
> What I found
> With the default 128M CMA, the allocation of 257 pages (~1MB) fails
> After increasing CMA to 256M (by adding cma=256M to the kernel command line), the error disappears and WiFi works correctly
>
> My questions
> Is 128M expected to be sufficient for ath12k on this platform?
> Could the driver be optimized to need less contiguous memory?
> Should the default CMA size be increased to 256M for X1E80100 devices?
The default value in the arm64 defconfig is CONFIG_CMA_SIZE_MBYTES=32,
although most laptop DTs individually add a 128M zone under /reserved-memory
We should probably enlarge this value in either of those places, although I
don't know whether changing the defconfig is going to be welcomed..
Konrad
^ permalink raw reply
* Re: [PATCH 24/62] net/cw1200: Fix locking in error paths
From: Johannes Berg @ 2026-03-02 11:08 UTC (permalink / raw)
To: Bart Van Assche, Peter Zijlstra
Cc: Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long, linux-kernel,
Marco Elver, Christoph Hellwig, Steven Rostedt, Nick Desaulniers,
Nathan Chancellor, Kees Cook, Jann Horn, Bart Van Assche,
Kalle Valo, linux-wireless
In-Reply-To: <20260223220102.2158611-25-bart.vanassche@linux.dev>
On Mon, 2026-02-23 at 14:00 -0800, Bart Van Assche wrote:
> From: Bart Van Assche <bvanassche@acm.org>
>
> cw1200_wow_suspend() must only return with priv->conf_mutex locked if it
> returns zero. This mutex must be unlocked if an error is returned. Add
> mutex_unlock() calls to the error paths from which that call is missing.
> This has been detected by the Clang thread-safety analyzer.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Cc: linux-wireless@vger.kernel.org
This, and 25, are part of a larger series and I didn't get a cover
letter, so not sure what's supposed to happen with it.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v5 2/2] wifi: mac80211_hwsim: add incumbent signal interference detection support
From: Johannes Berg @ 2026-03-02 8:22 UTC (permalink / raw)
To: Amith A; +Cc: linux-wireless, Aditya Kumar Singh
In-Reply-To: <20260216032027.2310956-3-amith.a@oss.qualcomm.com>
Hi,
FWIW, I'm applying patch 1 of this.
This didn't apply now due to some overlap with the radar patches, but
that's not really the issue.
> +static ssize_t hwsim_simulate_incumbent_signal_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *ppos)
> +{
> + struct mac80211_hwsim_data *data = file->private_data;
> + struct ieee80211_chanctx_conf *chanctx_conf = NULL;
> + struct hwsim_chanctx_iter_arg arg;
> + u32 freq_mhz, bitmap;
> + char *sptr, *token;
> + char buf[64];
> +
> + if (!len || len >= sizeof(buf))
> + return -EINVAL;
> +
> + if (copy_from_user(buf, ubuf, len))
> + return -EFAULT;
> + buf[len] = '\0';
If len == 64, then you have a bug here. Need to further restrict the
length check, e.g. by using sizeof(buf)-1 above.
> + strim(buf);
> + sptr = buf;
> + token = strsep(&sptr, " \t");
> + if (!token)
> + return -EINVAL;
> + if (kstrtou32(token, 0, &freq_mhz))
> + return -EINVAL;
> +
> + token = strsep(&sptr, " \t");
> + if (!token)
> + return -EINVAL;
> + if (kstrtou32(token, 0, &bitmap))
> + return -EINVAL;
> +
> + if (!freq_mhz)
> + return -EINVAL;
> +
> + arg.out = &chanctx_conf;
> + arg.freq_mhz = freq_mhz;
> + ieee80211_iter_chan_contexts_atomic(data->hw,
> + hwsim_6ghz_chanctx_iter,
> + &arg);
> +
> + if (!chanctx_conf)
> + return -EINVAL;
This seems overly complex? You can init "... arg = {}" and then you
don't need the freq_mhz or chanctx_conf variables, just use the "arg."
versions directly for all of the code.
I also think it might be nicer overall to use sscanf()? I don't really
think there's any reason for allowing space and \t, after all this is
specific userspace for testing, it can be made to write the precise
format the kernel expects.
johannes
^ permalink raw reply
* Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
From: Johannes Berg @ 2026-03-02 8:07 UTC (permalink / raw)
To: Ben Greear, linux-wireless; +Cc: Korenblit, Miriam Rachel, linux-mm
In-Reply-To: <e7d92fab-9d0e-4a58-aa0b-2c6545772e68@candelatech.com>
On Sun, 2026-03-01 at 07:38 -0800, Ben Greear wrote:
> On 2/27/26 08:31, Ben Greear wrote:
> > On 2/23/26 14:36, Ben Greear wrote:
> > > Hello,
> > >
> > > I hit a deadlock related to CMA mem allocation attempting to flush all work
> > > while holding some wifi related mutex, and with a work-queue attempting to process a wifi regdomain
> > > work item. I really don't see any good way to fix this,
> > > it would seem that any code that was holding a mutex that could block a work-queue
> > > cannot safely allocate CMA memory? Hopefully someone else has a better idea.
> >
> > I tried using a kthread to do the regulatory domain processing instead of worker item,
> > and that seems to have solved the problem. If that seems reasonable approach to
> > wifi stack folks, I can post a patch.
>
> The other net/wireless work-item 'disconnect_work' also needs to be moved to the kthread
> for the same reason....
I don't think we want to use a kthread for this, it doesn't really make
sense.
Was this with lockdep? If so, it complain about anything?
I'm having a hard time seeing why it would deadlock at all when wifi
uses schedule_work() and therefore the system_percpu_wq, and
__lru_add_drain_all() flushes lru_add_drain_work on mm_percpu_wq, and
lru_add_and_bh_lrus_drain() doesn't really _seem_ to do anything related
to RTNL etc.?
I think we need a real explanation here rather than "if I randomly
change this, it no longer appears".
johannes
^ permalink raw reply
* RE: [PATCH] wifi: rtl8xxxu: fix potential use of uninitialized value
From: Ping-Ke Shih @ 2026-03-02 7:23 UTC (permalink / raw)
To: Yi Cong, Jes.Sorensen@gmail.com
Cc: linux-wireless@vger.kernel.org, Yi Cong, stable@vger.kernel.org
In-Reply-To: <20260227073708.508772-1-cong.yi@linux.dev>
Yi Cong <cong.yi@linux.dev> wrote:
> From: Yi Cong <yicong@kylinos.cn>
>
> The local variables 'mcs' and 'nss' in rtl8xxxu_update_ra_report() are
> passed to rtl8xxxu_desc_to_mcsrate() as output parameters. If the helper
> function encounters an unhandled rate index, it may return without setting
> these values, leading to the use of uninitialized stack data.
>
> Initialize 'mcs' to 0 and 'nss' to 1 at declaration to ensure safe defaults
> (MCS 0, 1 spatial stream) are used even if parsing fails. Note that 'nss'
> must be at least 1 to be valid.
>
> Fixes: 7de16123d9e2 ("wifi: rtl8xxxu: Introduce rtl8xxxu_update_ra_report")
> Cc: stable@vger.kernel.org
> Signed-off-by: Yi Cong <yicong@kylinos.cn>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> index 794187d28caa..d0035960f8d4 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
> @@ -4820,7 +4820,7 @@ static void rtl8xxxu_set_aifs(struct rtl8xxxu_priv *priv, u8 slot_time)
> void rtl8xxxu_update_ra_report(struct rtl8xxxu_ra_report *rarpt,
> u8 rate, u8 sgi, u8 bw)
> {
> - u8 mcs, nss;
> + u8 mcs = 0, nss = 1;
>
> rarpt->txrate.flags = 0;
With ` rarpt->txrate.flags |= RATE_INFO_FLAGS_MCS;` in rtl8xxxu_update_ra_report(),
I believe rtl8xxxu can only support HT rate, so no need 'nss' which is for VHT rate.
I think the correct fix is something like
if (rate <= DESC_RATE_54M) {
// does something as current
} else if (rate >= DESC_RATE_MCS0 && rate <= DESC_RATE_MCS15) {
mcs = rate - DESC_RATE_MCS0;
// and HT flags
} else {
return; // do nothing for unexpected rate
}
// fill common flags for legacy and HT rate.
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: mac80211: give the AP more time for EPPKE as well
From: Johannes Berg @ 2026-03-02 7:18 UTC (permalink / raw)
To: linux-wireless; +Cc: Kavita Kavita
In-Reply-To: <20260128132414.881741-2-johannes@sipsolutions.net>
On Wed, 2026-01-28 at 14:24 +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> EPPKE authentication can use SAE (via PASN), so give the
> AP more time to respond to EPPKE case just like for SAE.
Any comments on this from AP folks?
Are we expecting APs that supported EPPKE to be much faster? It seems
unlikely to me?
johannes
^ permalink raw reply
* [PATCH v2 wireless-next] wifi: cfg80211: make cluster id an array
From: Miri Korenblit @ 2026-03-02 7:11 UTC (permalink / raw)
To: linux-wireless
cfg80211_nan_conf::cluster_id is currently a pointer, but there is no real
reason to not have it an array. It makes things easier as there is no
need to check the pointer validity each time.
If a cluster ID wasn't provided by user space it will be randomized.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
---
v2: fixed hwsim to not check if cluster_id is not NULL.
drivers/net/wireless/intel/iwlwifi/mld/nan.c | 5 ++---
drivers/net/wireless/virtual/mac80211_hwsim.c | 2 +-
include/net/cfg80211.h | 3 +--
net/mac80211/cfg.c | 12 ++----------
net/wireless/nl80211.c | 14 +++++++++++---
5 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mld/nan.c b/drivers/net/wireless/intel/iwlwifi/mld/nan.c
index 2dbd3d58b0c6..4d8e85f2bd7c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mld/nan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mld/nan.c
@@ -54,9 +54,8 @@ static int iwl_mld_nan_config(struct iwl_mld *mld,
ether_addr_copy(cmd.nmi_addr, vif->addr);
cmd.master_pref = conf->master_pref;
- if (conf->cluster_id)
- memcpy(cmd.cluster_id, conf->cluster_id + 4,
- sizeof(cmd.cluster_id));
+ memcpy(cmd.cluster_id, conf->cluster_id + 4,
+ sizeof(cmd.cluster_id));
cmd.scan_period = conf->scan_period < 255 ? conf->scan_period : 255;
cmd.dwell_time =
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index e89173f91637..b69e730108ea 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -4078,7 +4078,7 @@ static int mac80211_hwsim_start_nan(struct ieee80211_hw *hw,
ns_to_ktime(until_dw * NSEC_PER_USEC),
HRTIMER_MODE_REL_SOFT);
- if (conf->cluster_id && !is_zero_ether_addr(conf->cluster_id) &&
+ if (!is_zero_ether_addr(conf->cluster_id) &&
is_zero_ether_addr(hwsim_nan_cluster_id)) {
memcpy(hwsim_nan_cluster_id, conf->cluster_id, ETH_ALEN);
} else if (is_zero_ether_addr(hwsim_nan_cluster_id)) {
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index fc01de19c798..73f4aa15c956 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4020,7 +4020,6 @@ struct cfg80211_nan_band_config {
* (i.e. BIT(NL80211_BAND_2GHZ)).
* @cluster_id: cluster ID used for NAN synchronization. This is a MAC address
* that can take a value from 50-6F-9A-01-00-00 to 50-6F-9A-01-FF-FF.
- * If NULL, the device will pick a random Cluster ID.
* @scan_period: period (in seconds) between NAN scans.
* @scan_dwell_time: dwell time (in milliseconds) for NAN scans.
* @discovery_beacon_interval: interval (in TUs) for discovery beacons.
@@ -4036,7 +4035,7 @@ struct cfg80211_nan_band_config {
struct cfg80211_nan_conf {
u8 master_pref;
u8 bands;
- const u8 *cluster_id;
+ u8 cluster_id[ETH_ALEN] __aligned(2);
u16 scan_period;
u16 scan_dwell_time;
u8 discovery_beacon_interval;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index b92b4a5c2636..490e2d9b1720 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -330,7 +330,6 @@ static void ieee80211_stop_p2p_device(struct wiphy *wiphy,
static void ieee80211_nan_conf_free(struct cfg80211_nan_conf *conf)
{
- kfree(conf->cluster_id);
kfree(conf->extra_nan_attrs);
kfree(conf->vendor_elems);
memset(conf, 0, sizeof(*conf));
@@ -372,9 +371,6 @@ static int ieee80211_nan_conf_copy(struct cfg80211_nan_conf *dst,
memcpy(&dst->band_cfgs, &src->band_cfgs,
sizeof(dst->band_cfgs));
- kfree(dst->cluster_id);
- dst->cluster_id = NULL;
-
kfree(dst->extra_nan_attrs);
dst->extra_nan_attrs = NULL;
dst->extra_nan_attrs_len = 0;
@@ -383,12 +379,8 @@ static int ieee80211_nan_conf_copy(struct cfg80211_nan_conf *dst,
dst->vendor_elems = NULL;
dst->vendor_elems_len = 0;
- if (src->cluster_id) {
- dst->cluster_id = kmemdup(src->cluster_id, ETH_ALEN,
- GFP_KERNEL);
- if (!dst->cluster_id)
- goto no_mem;
- }
+ if (is_zero_ether_addr(dst->cluster_id))
+ ether_addr_copy(dst->cluster_id, src->cluster_id);
if (src->extra_nan_attrs && src->extra_nan_attrs_len) {
dst->extra_nan_attrs = kmemdup(src->extra_nan_attrs,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b94231c8441c..e220ccbba91b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -21,6 +21,7 @@
#include <linux/nospec.h>
#include <linux/etherdevice.h>
#include <linux/if_vlan.h>
+#include <linux/random.h>
#include <net/net_namespace.h>
#include <net/genetlink.h>
#include <net/cfg80211.h>
@@ -15725,9 +15726,16 @@ static int nl80211_parse_nan_conf(struct wiphy *wiphy,
return err;
changed |= CFG80211_NAN_CONF_CHANGED_CONFIG;
- if (attrs[NL80211_NAN_CONF_CLUSTER_ID] && start)
- conf->cluster_id =
- nla_data(attrs[NL80211_NAN_CONF_CLUSTER_ID]);
+ if (attrs[NL80211_NAN_CONF_CLUSTER_ID] && start) {
+ ether_addr_copy(conf->cluster_id,
+ nla_data(attrs[NL80211_NAN_CONF_CLUSTER_ID]));
+ } else if (start) {
+ conf->cluster_id[0] = 0x50;
+ conf->cluster_id[1] = 0x6f;
+ conf->cluster_id[2] = 0x9a;
+ conf->cluster_id[3] = 0x01;
+ get_random_bytes(&conf->cluster_id[4], 2);
+ }
if (attrs[NL80211_NAN_CONF_EXTRA_ATTRS]) {
conf->extra_nan_attrs =
--
2.34.1
^ permalink raw reply related
* Re: [PATCH wireless-next 23/35] wifi: mm81x: add sdio.c
From: Lachlan Hodges @ 2026-03-02 6:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: johannes, Dan Callaghan, Arien Judge, ayman.grais, linux-wireless,
linux-kernel
In-Reply-To: <20260227-spotted-rugged-moth-3fdcbe@quoll>
> > +{
> > + int ret;
> > +
> > + ret = sdio_register_driver(&mm81x_sdio_driver);
> > + if (ret)
> > + pr_err("sdio_register_driver() failed: %d\n", ret);
> > +
> > + return ret;
>
> And you miss here module description. This patch organized per files,
> not per logical pieces, makes it very difficult to review. I have
> absolutely no clue whether this is module or not, whether this is built
> or not, whether it is complete or not.
This patchset was structured similarly to how ath12k was structured
by Kalle [1], in his first and second series revisions, where each file
is split into a separate patch for review and then it's squashed into
a single commit once accepted. Admittedly, ath12k did not contain
anything pertinent to separate subsystems, where we have DT bindings
and mmc ID that require ACKs from their respective maintainers.
For example, if we include the MMC SDIO ID in our sdio.c patchset
such that it is "used" we would be using the wireless subsystem
commit message format rather then the MMC SDIO format that is
traditionally used when updating the sdio_ids.h file. Noting that
existing commits to sdio_ids.h are individual commits adding the
SDIO ID and then used in later commits.
Ultimately the structure of our commits is up to Johannes since we are
going through the wireless tree, but since we have patches that
touch different subsytems that also needs to be considered. Open to
suggestions :).
[1] https://lore.kernel.org/linux-wireless/20220812161003.27279-1-kvalo@kernel.org/
--
Appreciate the review Krzysztof, will address your other comments
in a separate mail.
lachlan
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure
From: Christian Hewitt @ 2026-03-02 6:17 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Bitterblue Smith, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <c764f16a880a400686c8c5f639fa98c3@realtek.com>
> On 2 Mar 2026, at 10:04 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>>>
>>> Christian Hewitt <christianshewitt@gmail.com> wrote:
>>>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
>>>> physical map dump intermittently fails with -EBUSY during probe.
>>>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
>>>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
>>>> bit after 1 second.
>>>
>>> I'm checking internally how we handle this case.
>>>
>>> [...]
>>>
>>>>
>>>> For context, firmware also fails (and recovers) sometimes:
>>>
>>> Did you mean this doesn't always happen? sometimes?
>>
>> It’s another intermittent behaviour observed on this board (and not
>> related to the issue this patch targets). It occurs less frequently
>> than the efuse issue and the existing retry mechanism in the driver
>> ensures firmware load always succeeds.
>
> As intermittent behaviour, it might be not worth to try DMA.
>
> Recently, we have some patches related to PCI hardware settings. Please
> use the latest driver including patch [1] to see if it can be stable.
>
> [1] af1e82232b98 ("wifi: rtw89: pci: restore LDO setting after device resume")
The efuse fail snippet that I posted alongside the patch was from a
Linux 7.0-rc1 kernel so that patch was already present.
>> We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
>>> bit DMA to see if it can resolve problem in your platform.
>>
>> I can experiment but this doesn’t happen often so I probably can’t
>> provide meaningful feedback.
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure
From: Ping-Ke Shih @ 2026-03-02 6:04 UTC (permalink / raw)
To: Christian Hewitt
Cc: Bitterblue Smith, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <E6E752BD-5F3D-4F30-9820-CB44FA767E69@gmail.com>
Christian Hewitt <christianshewitt@gmail.com> wrote:
> > On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Christian Hewitt <christianshewitt@gmail.com> wrote:
> >> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
> >> physical map dump intermittently fails with -EBUSY during probe.
> >> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
> >> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
> >> bit after 1 second.
> >
> > I'm checking internally how we handle this case.
> >
> > [...]
> >
> >>
> >> For context, firmware also fails (and recovers) sometimes:
> >
> > Did you mean this doesn't always happen? sometimes?
>
> It’s another intermittent behaviour observed on this board (and not
> related to the issue this patch targets). It occurs less frequently
> than the efuse issue and the existing retry mechanism in the driver
> ensures firmware load always succeeds.
As intermittent behaviour, it might be not worth to try DMA.
Recently, we have some patches related to PCI hardware settings. Please
use the latest driver including patch [1] to see if it can be stable.
[1] af1e82232b98 ("wifi: rtw89: pci: restore LDO setting after device resume")
>
> > We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
> > bit DMA to see if it can resolve problem in your platform.
>
> I can experiment but this doesn’t happen often so I probably can’t
> provide meaningful feedback.
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure
From: Christian Hewitt @ 2026-03-02 5:55 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Bitterblue Smith, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <c751f9505a664f6895bacecb62bc534a@realtek.com>
> On 2 Mar 2026, at 9:47 am, Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Christian Hewitt <christianshewitt@gmail.com> wrote:
>> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
>> physical map dump intermittently fails with -EBUSY during probe.
>> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
>> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
>> bit after 1 second.
>
> I'm checking internally how we handle this case.
>
> [...]
>
>>
>> For context, firmware also fails (and recovers) sometimes:
>
> Did you mean this doesn't always happen? sometimes?
It’s another intermittent behaviour observed on this board (and not
related to the issue this patch targets). It occurs less frequently
than the efuse issue and the existing retry mechanism in the driver
ensures firmware load always succeeds.
> We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
> bit DMA to see if it can resolve problem in your platform.
I can experiment but this doesn’t happen often so I probably can’t
provide meaningful feedback.
Christian
> diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
> index 43c61b3dc969..9d003ab93c85 100644
> --- a/drivers/net/wireless/realtek/rtw89/pci.c
> +++ b/drivers/net/wireless/realtek/rtw89/pci.c
> @@ -3305,6 +3305,8 @@ static bool rtw89_pci_is_dac_compatible_bridge(struct rtw89_dev *rtwdev)
> if (!bridge)
> return false;
>
> + return true; // or force to return false;
> +
> switch (bridge->vendor) {
> case PCI_VENDOR_ID_INTEL:
> return true;
>
>>
>> ROCK5B:~ # dmesg | grep rtw89
>> [ 6.436873] rtw89_8852be 0002:21:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
>> [ 6.437165] rtw89_8852be 0002:21:00.0: enabling device (0000 -> 0003)
>> [ 6.450228] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 5
>> [ 6.450239] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 3
>> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail
>> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail
>> [ 7.864160] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x1E0 = 0x62
>> [ 7.864165] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x83F0 = 0x80011
>> [ 7.864173] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864188] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864203] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864219] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864234] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864250] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864265] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864281] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864296] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864311] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864327] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864342] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
>> [ 7.864358] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864373] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 7.864387] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
>> [ 8.181342] rtw89_8852be 0002:21:00.0: chip info CID: 0, CV: 1, AID: 0, ACV: 1, RFE: 1
>> [ 8.184322] rtw89_8852be 0002:21:00.0: rfkill hardware state changed to enable
>>
>
>
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: retry efuse physical map dump on transient failure
From: Ping-Ke Shih @ 2026-03-02 5:47 UTC (permalink / raw)
To: Christian Hewitt, Bitterblue Smith,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260301042422.195491-1-christianshewitt@gmail.com>
Christian Hewitt <christianshewitt@gmail.com> wrote:
> On Radxa Rock 5B with a RTL8852BE combo WiFi/BT card, the efuse
> physical map dump intermittently fails with -EBUSY during probe.
> The failure occurs in rtw89_dump_physical_efuse_map_ddv() where
> read_poll_timeout_atomic() times out waiting for the B_AX_EF_RDY
> bit after 1 second.
I'm checking internally how we handle this case.
[...]
>
> For context, firmware also fails (and recovers) sometimes:
Did you mean this doesn't always happen? sometimes?
We has seen similar log because of 36-bit DMA. Try below to force 32- or 36-
bit DMA to see if it can resolve problem in your platform.
diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c
index 43c61b3dc969..9d003ab93c85 100644
--- a/drivers/net/wireless/realtek/rtw89/pci.c
+++ b/drivers/net/wireless/realtek/rtw89/pci.c
@@ -3305,6 +3305,8 @@ static bool rtw89_pci_is_dac_compatible_bridge(struct rtw89_dev *rtwdev)
if (!bridge)
return false;
+ return true; // or force to return false;
+
switch (bridge->vendor) {
case PCI_VENDOR_ID_INTEL:
return true;
>
> ROCK5B:~ # dmesg | grep rtw89
> [ 6.436873] rtw89_8852be 0002:21:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin
> [ 6.437165] rtw89_8852be 0002:21:00.0: enabling device (0000 -> 0003)
> [ 6.450228] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 5
> [ 6.450239] rtw89_8852be 0002:21:00.0: Firmware version 0.29.29.15 (6fb3ec41), cmd version 0, type 3
> [ 7.864148] rtw89_8852be 0002:21:00.0: fw security fail
> [ 7.864154] rtw89_8852be 0002:21:00.0: download firmware fail
> [ 7.864160] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x1E0 = 0x62
> [ 7.864165] rtw89_8852be 0002:21:00.0: [ERR]fwdl 0x83F0 = 0x80011
> [ 7.864173] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864188] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864203] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864219] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864234] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864250] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864265] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864281] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864296] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864311] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864327] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864342] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931150
> [ 7.864358] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864373] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 7.864387] rtw89_8852be 0002:21:00.0: [ERR]fw PC = 0xb8931154
> [ 8.181342] rtw89_8852be 0002:21:00.0: chip info CID: 0, CV: 1, AID: 0, ACV: 1, RFE: 1
> [ 8.184322] rtw89_8852be 0002:21:00.0: rfkill hardware state changed to enable
>
^ permalink raw reply related
* [PATCH] iw: util: Fix 6 GHz 80 MHz CF1 configuration
From: Hariharan Basuthkar @ 2026-03-02 4:03 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Hariharan Basuthkar
Fix the 80 MHz base-frequency table used by get_cf1().
Replace the incorrect 6195 MHz entry with 6915 MHz in bw80[] so center_freq1
is computed correctly for 6 GHz 80 MHz channels.
Signed-off-by: Hariharan Basuthkar <hariharan.basuthkar@oss.qualcomm.com>
---
util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util.c b/util.c
index 06c3347..e6d42e5 100644
--- a/util.c
+++ b/util.c
@@ -2097,7 +2097,7 @@ int get_cf1(const struct chanmode *chanmode, unsigned long freq)
unsigned int bw80[] = { 5180, 5260, 5500, 5580, 5660, 5745,
5955, 6035, 6115, 6195, 6275, 6355,
6435, 6515, 6595, 6675, 6755, 6835,
- 6195, 6995 };
+ 6915, 6995 };
unsigned int bw160[] = { 5180, 5500, 5955, 6115, 6275, 6435,
6595, 6755, 6915 };
/* based on 11be D2 E.1 Country information and operating classes */
base-commit: b9f9dda5898bd03ae679922e424097f556351790
--
2.34.1
^ permalink raw reply related
* Re: [PATCH ath-next] wifi: ath12k: Remove the unused argument from the Rx data path
From: Baochen Qiang @ 2026-03-02 1:33 UTC (permalink / raw)
To: Karthikeyan Periyasamy, ath12k; +Cc: linux-wireless
In-Reply-To: <20260227042128.3494167-1-karthikeyan.periyasamy@oss.qualcomm.com>
On 2/27/2026 12:21 PM, Karthikeyan Periyasamy wrote:
> Currently, the Rx path uses new infrastructure to extract the required HAL
> parameters. Consequently, the HAL Rx descriptor argument is no longer
> needed in the following helper functions. Remove the unused argument from
> the following helper functions.
>
> ath12k_dp_rx_h_undecap()
> ath12k_dp_rx_check_nwifi_hdr_len_valid()
> ath12k_wifi7_dp_rx_h_mpdu()
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>
> Signed-off-by: Karthikeyan Periyasamy <karthikeyan.periyasamy@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/dp_rx.c | 2 --
> drivers/net/wireless/ath/ath12k/dp_rx.h | 2 --
> drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c | 25 ++++++++-----------
> 3 files changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/dp_rx.c b/drivers/net/wireless/ath/ath12k/dp_rx.c
> index a32ee9f8061a..c0e2b2c1a292 100644
> --- a/drivers/net/wireless/ath/ath12k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath12k/dp_rx.c
> @@ -1117,7 +1117,6 @@ static void ath12k_dp_rx_h_undecap_eth(struct ath12k_pdev_dp *dp_pdev,
> }
>
> void ath12k_dp_rx_h_undecap(struct ath12k_pdev_dp *dp_pdev, struct sk_buff *msdu,
> - struct hal_rx_desc *rx_desc,
> enum hal_encrypt_type enctype,
> bool decrypted,
> struct hal_rx_desc_data *rx_info)
> @@ -1393,7 +1392,6 @@ void ath12k_dp_rx_deliver_msdu(struct ath12k_pdev_dp *dp_pdev, struct napi_struc
> EXPORT_SYMBOL(ath12k_dp_rx_deliver_msdu);
>
> bool ath12k_dp_rx_check_nwifi_hdr_len_valid(struct ath12k_dp *dp,
> - struct hal_rx_desc *rx_desc,
> struct sk_buff *msdu,
> struct hal_rx_desc_data *rx_info)
> {
> diff --git a/drivers/net/wireless/ath/ath12k/dp_rx.h b/drivers/net/wireless/ath/ath12k/dp_rx.h
> index 1ec5382f5995..bd62af0c80d4 100644
> --- a/drivers/net/wireless/ath/ath12k/dp_rx.h
> +++ b/drivers/net/wireless/ath/ath12k/dp_rx.h
> @@ -189,7 +189,6 @@ void ath12k_dp_extract_rx_desc_data(struct ath12k_hal *hal,
> }
>
> void ath12k_dp_rx_h_undecap(struct ath12k_pdev_dp *dp_pdev, struct sk_buff *msdu,
> - struct hal_rx_desc *rx_desc,
> enum hal_encrypt_type enctype,
> bool decrypted,
> struct hal_rx_desc_data *rx_info);
> @@ -197,7 +196,6 @@ void ath12k_dp_rx_deliver_msdu(struct ath12k_pdev_dp *dp_pdev, struct napi_struc
> struct sk_buff *msdu,
> struct hal_rx_desc_data *rx_info);
> bool ath12k_dp_rx_check_nwifi_hdr_len_valid(struct ath12k_dp *dp,
> - struct hal_rx_desc *rx_desc,
> struct sk_buff *msdu,
> struct hal_rx_desc_data *rx_info);
> u64 ath12k_dp_rx_h_get_pn(struct ath12k_dp *dp, struct sk_buff *skb);
> diff --git a/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c b/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c
> index 7450938adf65..77a1679b41df 100644
> --- a/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath12k/wifi7/dp_rx.c
> @@ -325,7 +325,6 @@ static void ath12k_wifi7_dp_rx_h_csum_offload(struct sk_buff *msdu,
>
> static void ath12k_wifi7_dp_rx_h_mpdu(struct ath12k_pdev_dp *dp_pdev,
> struct sk_buff *msdu,
> - struct hal_rx_desc *rx_desc,
> struct hal_rx_desc_data *rx_info)
> {
> struct ath12k_skb_rxcb *rxcb;
> @@ -388,8 +387,7 @@ static void ath12k_wifi7_dp_rx_h_mpdu(struct ath12k_pdev_dp *dp_pdev,
> }
>
> ath12k_wifi7_dp_rx_h_csum_offload(msdu, rx_info);
> - ath12k_dp_rx_h_undecap(dp_pdev, msdu, rx_desc,
> - enctype, is_decrypted, rx_info);
> + ath12k_dp_rx_h_undecap(dp_pdev, msdu, enctype, is_decrypted, rx_info);
>
> if (!is_decrypted || rx_info->is_mcbc)
> return;
> @@ -549,14 +547,14 @@ static int ath12k_wifi7_dp_rx_process_msdu(struct ath12k_pdev_dp *dp_pdev,
> }
> }
>
> - if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, rx_desc, msdu,
> + if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, msdu,
> rx_info))) {
> ret = -EINVAL;
> goto free_out;
> }
>
> ath12k_dp_rx_h_ppdu(dp_pdev, rx_info);
> - ath12k_wifi7_dp_rx_h_mpdu(dp_pdev, msdu, rx_desc, rx_info);
> + ath12k_wifi7_dp_rx_h_mpdu(dp_pdev, msdu, rx_info);
>
> rx_info->rx_status->flag |= RX_FLAG_SKIP_MONITOR | RX_FLAG_DUP_VALIDATED;
>
> @@ -1030,13 +1028,13 @@ static int ath12k_wifi7_dp_rx_h_verify_tkip_mic(struct ath12k_pdev_dp *dp_pdev,
> RX_FLAG_IV_STRIPPED | RX_FLAG_DECRYPTED;
> skb_pull(msdu, hal_rx_desc_sz);
>
> - if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, rx_desc, msdu,
> + if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, msdu,
> rx_info)))
> return -EINVAL;
>
> ath12k_dp_rx_h_ppdu(dp_pdev, rx_info);
> - ath12k_dp_rx_h_undecap(dp_pdev, msdu, rx_desc,
> - HAL_ENCRYPT_TYPE_TKIP_MIC, true, rx_info);
> + ath12k_dp_rx_h_undecap(dp_pdev, msdu, HAL_ENCRYPT_TYPE_TKIP_MIC, true,
> + rx_info);
> ieee80211_rx(ath12k_pdev_dp_to_hw(dp_pdev), msdu);
> return -EINVAL;
> }
> @@ -1588,7 +1586,6 @@ static int ath12k_wifi7_dp_rx_h_null_q_desc(struct ath12k_pdev_dp *dp_pdev,
> struct ath12k_dp *dp = dp_pdev->dp;
> struct ath12k_base *ab = dp->ab;
> u16 msdu_len = rx_info->msdu_len;
> - struct hal_rx_desc *desc = (struct hal_rx_desc *)msdu->data;
> u8 l3pad_bytes = rx_info->l3_pad_bytes;
> struct ath12k_skb_rxcb *rxcb = ATH12K_SKB_RXCB(msdu);
> u32 hal_rx_desc_sz = dp->ab->hal.hal_desc_sz;
> @@ -1632,11 +1629,11 @@ static int ath12k_wifi7_dp_rx_h_null_q_desc(struct ath12k_pdev_dp *dp_pdev,
> skb_put(msdu, hal_rx_desc_sz + l3pad_bytes + msdu_len);
> skb_pull(msdu, hal_rx_desc_sz + l3pad_bytes);
> }
> - if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, desc, msdu, rx_info)))
> + if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, msdu, rx_info)))
> return -EINVAL;
>
> ath12k_dp_rx_h_ppdu(dp_pdev, rx_info);
> - ath12k_wifi7_dp_rx_h_mpdu(dp_pdev, msdu, desc, rx_info);
> + ath12k_wifi7_dp_rx_h_mpdu(dp_pdev, msdu, rx_info);
>
> rxcb->tid = rx_info->tid;
>
> @@ -1673,7 +1670,7 @@ static bool ath12k_wifi7_dp_rx_h_tkip_mic_err(struct ath12k_pdev_dp *dp_pdev,
> skb_put(msdu, hal_rx_desc_sz + l3pad_bytes + msdu_len);
> skb_pull(msdu, hal_rx_desc_sz + l3pad_bytes);
>
> - if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, desc, msdu, rx_info)))
> + if (unlikely(!ath12k_dp_rx_check_nwifi_hdr_len_valid(dp, msdu, rx_info)))
> return true;
>
> ath12k_dp_rx_h_ppdu(dp_pdev, rx_info);
> @@ -1681,8 +1678,8 @@ static bool ath12k_wifi7_dp_rx_h_tkip_mic_err(struct ath12k_pdev_dp *dp_pdev,
> rx_info->rx_status->flag |= (RX_FLAG_MMIC_STRIPPED | RX_FLAG_MMIC_ERROR |
> RX_FLAG_DECRYPTED);
>
> - ath12k_dp_rx_h_undecap(dp_pdev, msdu, desc,
> - HAL_ENCRYPT_TYPE_TKIP_MIC, false, rx_info);
> + ath12k_dp_rx_h_undecap(dp_pdev, msdu, HAL_ENCRYPT_TYPE_TKIP_MIC, false,
> + rx_info);
> return false;
> }
>
>
> base-commit: ff49eba595df500e4ddccc593088c8a4ab5f2c27
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: Pass the correct value of each TID during a stop AMPDU session
From: Baochen Qiang @ 2026-03-02 1:32 UTC (permalink / raw)
To: Reshma Immaculate Rajkumar, ath12k; +Cc: linux-wireless
In-Reply-To: <20260227110123.3726354-1-reshma.rajkumar@oss.qualcomm.com>
On 2/27/2026 7:01 PM, Reshma Immaculate Rajkumar wrote:
> With traffic ongoing for data TID [TID 0], an DELBA request to
> stop AMPDU for the BA session was received on management TID [TID 4].
> The corresponding TID number was incorrectly passed to stop the BA session,
> resulting in the BA session for data TIDs being stopped and the BA size
> being reduced to 1, causing an overall dip in TCP throughput.
>
> Fix this issue by passing the correct argument from
> ath12k_dp_rx_ampdu_stop() to ath12k_dp_arch_peer_rx_tid_reo_update()
> during an AMPDU stop session. Instead of passing peer->dp_peer->rx_tid,
> which is the base address of the array, corresponding to TID 0, pass
> the value of &peer->dp_peer->rx_tid[params->tid]. With this, the
> different TID numbers are accounted for.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1
>
> Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
> Signed-off-by: Reshma Immaculate Rajkumar <reshma.rajkumar@oss.qualcomm.com>
> ---
> v2:
> * modify 'ADDBA' to 'DELBA' request in commit message
> drivers/net/wireless/ath/ath12k/dp_rx.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/dp_rx.c b/drivers/net/wireless/ath/ath12k/dp_rx.c
> index a32ee9f8061a..640f752eaa03 100644
> --- a/drivers/net/wireless/ath/ath12k/dp_rx.c
> +++ b/drivers/net/wireless/ath/ath12k/dp_rx.c
> @@ -735,6 +735,7 @@ int ath12k_dp_rx_ampdu_stop(struct ath12k *ar,
> struct ath12k_dp *dp = ath12k_ab_to_dp(ab);
> struct ath12k_dp_link_peer *peer;
> struct ath12k_sta *ahsta = ath12k_sta_to_ahsta(params->sta);
> + struct ath12k_dp_rx_tid *rx_tid;
> struct ath12k_link_sta *arsta;
> int vdev_id;
> bool active;
> @@ -770,7 +771,8 @@ int ath12k_dp_rx_ampdu_stop(struct ath12k *ar,
> return 0;
> }
>
> - ret = ath12k_dp_arch_peer_rx_tid_reo_update(dp, peer, peer->dp_peer->rx_tid,
> + rx_tid = &peer->dp_peer->rx_tid[params->tid];
> + ret = ath12k_dp_arch_peer_rx_tid_reo_update(dp, peer, rx_tid,
> 1, 0, false);
> spin_unlock_bh(&dp->dp_lock);
> if (ret) {
>
> base-commit: 8bf22c33e7a172fbc72464f4cc484d23a6b412ba
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* RE: [REGRESSION] rtw89_8852ae: HT/VHT/HE not negotiated, stuck at 54 Mbps since kernel 6.18
From: Ping-Ke Shih @ 2026-03-02 1:30 UTC (permalink / raw)
To: Chris Wituchowski, linux-wireless@vger.kernel.org; +Cc: kvalo@kernel.org
In-Reply-To: <CAMX+G=Yd2fF+56+xFSzffO5Fq_PhkD41sBNkmFMpU5anN+QkmQ@mail.gmail.com>
Chris Wituchowski <flashrift@gmail.com> wrote:
> *resend as plaintext - sent originally as html, sorry!*
>
> Hi,
>
> I'm reporting a regression in the rtw89_8852ae driver. After upgrading from
> kernel 6.14.x (Fedora 42 GA) to 6.18.x (Fedora 43), my RTL8852AE WiFi adapter
> no longer negotiates HT, VHT, or HE with the access point. The connection falls
> back to legacy 802.11a at 54 Mbps on 5 GHz, delivering only ~20 Mbps real-world
> throughput on a gigabit link.
>
> == Hardware ==
>
> Adapter: Realtek RTL8852AE 802.11ax PCIe (WiFi 6, 2x2 MIMO)
> PCI ID: 10ec:8852 (subsystem: 17aa:4852, Lenovo)
> System: Lenovo laptop
>
> == Software ==
>
> Broken: 6.18.13-200.fc43.x86_64 (also 6.18.10, 6.18.12 — all broken)
> Last OK: 6.14.x (Fedora 42 GA kernel — WiFi worked at full 802.11ax speeds)
> Driver: rtw89_8852ae (in-tree)
> Firmware: rtw8852a_fw.bin (v0.13.36.2 / 52acc807)
> Distro: Fedora 43
>
> == Symptoms ==
>
> The adapter connects to a 5 GHz AP (channel 157) but fails to negotiate
> HT/VHT/HE, falling back to legacy 20 MHz / 54 Mbps:
>
> $ iw dev wlp3s0 link
> Connected to 52:bb:9f:a2:d8:4a (on wlp3s0)
> SSID: Innernette
> freq: 5785.0
> signal: -29 dBm
> rx bitrate: 54.0 MBit/s
> tx bitrate: 54.0 MBit/s
>
> $ iw dev wlp3s0 info
> channel 157 (5785 MHz), width: 20 MHz (no HT), center1: 5785 MHz
>
> Debugfs confirms the driver is not reporting any HT/VHT/HE capabilities
> for the station:
>
> /sys/kernel/debug/ieee80211/phy*/netdev:wlp3s0/stations/<bssid>/ht:
> "ht not supported"
>
> /sys/kernel/debug/ieee80211/phy*/netdev:wlp3s0/stations/<bssid>/vht:
> "VHT not supported"
>
> /sys/kernel/debug/ieee80211/phy*/netdev:wlp3s0/stations/<bssid>/he:
> "HE not supported"
>
> == AP Capabilities (confirmed via iw scan) ==
>
> The AP fully supports HT, VHT, and HE:
>
> - HT: HT20/HT40, MCS 0-15 (2 spatial streams)
> - VHT: up to 80 MHz, MCS 0-9 for 2 SS
> - HE (WiFi 6): full 802.11ax support
> - Max advertised rate: 1170 Mbps
>
> The AP's "HT protection" field shows "non-HT mixed mode", confirming it
> sees the client as a non-HT legacy station.
>
> == What I've Ruled Out ==
>
> 1. Signal strength: Excellent (-27 to -48 dBm across tests)
> 2. WPA3 vs WPA2: Same result with both (key-mgmt sae and psk)
> 3. wpa_supplicant vs iwd: Same result with both backends
> 4. Firmware: Already on latest version (v0.13.36.2)
> 5. Driver reload: Full unload/reload of rtw89 module stack — no change
> 6. Power save: Disabled (disable_ps_mode module parameter)
> 7. wl module conflict: Blacklisted via /etc/modprobe.d/blacklist-wl.conf
> 8. Regulatory: US domain active, DFS-FCC, correct for channel 157
> 9. Regression within 6.18.x: Changelogs for 6.18.10→6.18.13 contain
> ZERO rtw89/mac80211/cfg80211 changes. Bug exists across all 6.18.x.
>
> == Likely Cause ==
>
> Between kernel 6.14 and 6.18, the rtw89 driver received hundreds of commits
> for WiFi 7 MLO (Multi-Link Operation) support, including:
>
> - mac80211 per-link STA refactoring (HT/VHT/HE caps moved to per-link
> link_sta structures)
That should be compatible with WiFi 6 and earlier.
> - 54+ chanctx commits in rtw89 ("chan: manage active interfaces",
> "tweak setting of channel and TX power for MLO", etc.)
This driver is to support WiFi 6/7 chips. The WiFi 6 chips should work
as before these patches.
> - "disable EHT protocol by chip capabilities"
EHT is used WiFi 7 chips, so no worries about this.
>
> The RTL8852AE is a gen1 WiFi 6 chip. The MLO work was developed and tested
> primarily on gen2 WiFi 7 chips (RTL8922A/E). It appears the gen1 code path
> through the new per-link framework is not correctly populating HT/VHT/HE
> capabilities during association.
>
> == Steps to Reproduce ==
>
> 1. System with RTL8852AE (10ec:8852) running kernel 6.18.x
I tried two kernel 6.18.1 and 6.19.3 with same firmware 0.13.36.2 (52acc807)
that both work with HE rates.
I did connection by 'iw connect' command instead, because my AP is non-secure.
> 2. Connect to any 5 GHz 802.11ax access point
> 3. Observe: iw dev <if> info shows "width: 20 MHz (no HT)"
This is the output in my side:
channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
> 4. Observe: iw dev <if> link shows 54.0 MBit/s bitrate
This is the output in my office (the rate isn't good, but still HE rate)
rx bitrate: 600.4 MBit/s 80MHz HE-MCS 11 HE-NSS 1 HE-GI 0 HE-DCM 0
tx bitrate: 183.7 MBit/s 80MHz HE-MCS 2 HE-NSS 2 HE-GI 2 HE-DCM 0
> 5. Observe: debugfs ht/vht/he files all report "not supported"
This is the output in stations/<bssid>/ directory:
$ sudo cat *capa | grep supported
EHT not supported
HE supported
ht supported
VHT supported
>
> == Expected Result ==
>
> Connection should negotiate HT/VHT/HE (80 MHz, WiFi 6) as it did on
> kernel 6.14.x, providing 800+ Mbps link rates.
>
I don't have a Fedora on hand, and I tested above by Ubuntu + updated pre-built
kernel [1]. Please try if Ubuntu with 6.18.1 or 6.19.3 kernel can work in your side.
[1] https://kernel.ubuntu.com/mainline/v6.19.3/
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: account TX stats only when ACK/BA status is present
From: Baochen Qiang @ 2026-03-02 1:30 UTC (permalink / raw)
To: Sarika Sharma, ath12k; +Cc: linux-wireless
In-Reply-To: <20260226051947.1379716-1-sarika.sharma@oss.qualcomm.com>
On 2/26/2026 1:19 PM, Sarika Sharma wrote:
> The fields tx_retry_failed, tx_retry_count, and tx_duration are
> currently updated outside the HTT_PPDU_STATS_TAG_USR_COMPLTN_ACK_BA_STATUS
> flag check. In certain scenarios, firmware delivers multiple PPDU
> statistics for the same PPDU, first without BA/ACK information, and
> later with BA/ACK status once it becomes available. As the same PPDU
> is processed again, these counters are updated a second time,
> resulting in duplicate TX statistics.
>
> To address this, move the accounting of tx_retry_failed and
> tx_retry_count under the ACK/BA status flag check, and similarly gate
> tx_duration on the same path. This ensures that each PPDU contributes
> to these counters exactly once, avoids double counting, and provides
> consistent reporting in userspace tools such as station dump.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>
> Fixes: a0b963e1da5b ("wifi: ath12k: fetch tx_retry and tx_failed from htt_ppdu_stats_user_cmpltn_common_tlv")
> Signed-off-by: Sarika Sharma <sarika.sharma@oss.qualcomm.com>
> ---
> drivers/net/wireless/ath/ath12k/dp_htt.c | 24 +++++++++++++-----------
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/dp_htt.c b/drivers/net/wireless/ath/ath12k/dp_htt.c
> index cc71c5c5de5a..61c1c3b2350e 100644
> --- a/drivers/net/wireless/ath/ath12k/dp_htt.c
> +++ b/drivers/net/wireless/ath/ath12k/dp_htt.c
> @@ -205,16 +205,9 @@ ath12k_update_per_peer_tx_stats(struct ath12k_pdev_dp *dp_pdev,
> if (!(usr_stats->tlv_flags & BIT(HTT_PPDU_STATS_TAG_USR_RATE)))
> return;
>
> - if (usr_stats->tlv_flags & BIT(HTT_PPDU_STATS_TAG_USR_COMPLTN_COMMON)) {
> + if (usr_stats->tlv_flags & BIT(HTT_PPDU_STATS_TAG_USR_COMPLTN_COMMON))
> is_ampdu =
> HTT_USR_CMPLTN_IS_AMPDU(usr_stats->cmpltn_cmn.flags);
> - tx_retry_failed =
> - __le16_to_cpu(usr_stats->cmpltn_cmn.mpdu_tried) -
> - __le16_to_cpu(usr_stats->cmpltn_cmn.mpdu_success);
> - tx_retry_count =
> - HTT_USR_CMPLTN_LONG_RETRY(usr_stats->cmpltn_cmn.flags) +
> - HTT_USR_CMPLTN_SHORT_RETRY(usr_stats->cmpltn_cmn.flags);
> - }
>
> if (usr_stats->tlv_flags &
> BIT(HTT_PPDU_STATS_TAG_USR_COMPLTN_ACK_BA_STATUS)) {
> @@ -223,10 +216,19 @@ ath12k_update_per_peer_tx_stats(struct ath12k_pdev_dp *dp_pdev,
> HTT_PPDU_STATS_ACK_BA_INFO_NUM_MSDU_M);
> tid = le32_get_bits(usr_stats->ack_ba.info,
> HTT_PPDU_STATS_ACK_BA_INFO_TID_NUM);
> - }
>
> - if (common->fes_duration_us)
> - tx_duration = le32_to_cpu(common->fes_duration_us);
> + if (usr_stats->tlv_flags & BIT(HTT_PPDU_STATS_TAG_USR_COMPLTN_COMMON)) {
> + tx_retry_failed =
> + __le16_to_cpu(usr_stats->cmpltn_cmn.mpdu_tried) -
> + __le16_to_cpu(usr_stats->cmpltn_cmn.mpdu_success);
> + tx_retry_count =
> + HTT_USR_CMPLTN_LONG_RETRY(usr_stats->cmpltn_cmn.flags) +
> + HTT_USR_CMPLTN_SHORT_RETRY(usr_stats->cmpltn_cmn.flags);
> + }
> +
> + if (common->fes_duration_us)
> + tx_duration = le32_to_cpu(common->fes_duration_us);
> + }
>
> user_rate = &usr_stats->rate;
> flags = HTT_USR_RATE_PREAMBLE(user_rate->rate_flags);
>
> base-commit: 62f9b9b19939138c34ce0ac1e5d4969d617ecbb6
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply
* [REGRESSION] rtw89_8852ae: HT/VHT/HE not negotiated, stuck at 54 Mbps since kernel 6.18
From: Chris Wituchowski @ 2026-03-01 17:19 UTC (permalink / raw)
To: linux-wireless; +Cc: pkshih, kvalo
*resend as plaintext - sent originally as html, sorry!*
Hi,
I'm reporting a regression in the rtw89_8852ae driver. After upgrading from
kernel 6.14.x (Fedora 42 GA) to 6.18.x (Fedora 43), my RTL8852AE WiFi adapter
no longer negotiates HT, VHT, or HE with the access point. The connection falls
back to legacy 802.11a at 54 Mbps on 5 GHz, delivering only ~20 Mbps real-world
throughput on a gigabit link.
== Hardware ==
Adapter: Realtek RTL8852AE 802.11ax PCIe (WiFi 6, 2x2 MIMO)
PCI ID: 10ec:8852 (subsystem: 17aa:4852, Lenovo)
System: Lenovo laptop
== Software ==
Broken: 6.18.13-200.fc43.x86_64 (also 6.18.10, 6.18.12 — all broken)
Last OK: 6.14.x (Fedora 42 GA kernel — WiFi worked at full 802.11ax speeds)
Driver: rtw89_8852ae (in-tree)
Firmware: rtw8852a_fw.bin (v0.13.36.2 / 52acc807)
Distro: Fedora 43
== Symptoms ==
The adapter connects to a 5 GHz AP (channel 157) but fails to negotiate
HT/VHT/HE, falling back to legacy 20 MHz / 54 Mbps:
$ iw dev wlp3s0 link
Connected to 52:bb:9f:a2:d8:4a (on wlp3s0)
SSID: Innernette
freq: 5785.0
signal: -29 dBm
rx bitrate: 54.0 MBit/s
tx bitrate: 54.0 MBit/s
$ iw dev wlp3s0 info
channel 157 (5785 MHz), width: 20 MHz (no HT), center1: 5785 MHz
Debugfs confirms the driver is not reporting any HT/VHT/HE capabilities
for the station:
/sys/kernel/debug/ieee80211/phy*/netdev:wlp3s0/stations/<bssid>/ht:
"ht not supported"
/sys/kernel/debug/ieee80211/phy*/netdev:wlp3s0/stations/<bssid>/vht:
"VHT not supported"
/sys/kernel/debug/ieee80211/phy*/netdev:wlp3s0/stations/<bssid>/he:
"HE not supported"
== AP Capabilities (confirmed via iw scan) ==
The AP fully supports HT, VHT, and HE:
- HT: HT20/HT40, MCS 0-15 (2 spatial streams)
- VHT: up to 80 MHz, MCS 0-9 for 2 SS
- HE (WiFi 6): full 802.11ax support
- Max advertised rate: 1170 Mbps
The AP's "HT protection" field shows "non-HT mixed mode", confirming it
sees the client as a non-HT legacy station.
== What I've Ruled Out ==
1. Signal strength: Excellent (-27 to -48 dBm across tests)
2. WPA3 vs WPA2: Same result with both (key-mgmt sae and psk)
3. wpa_supplicant vs iwd: Same result with both backends
4. Firmware: Already on latest version (v0.13.36.2)
5. Driver reload: Full unload/reload of rtw89 module stack — no change
6. Power save: Disabled (disable_ps_mode module parameter)
7. wl module conflict: Blacklisted via /etc/modprobe.d/blacklist-wl.conf
8. Regulatory: US domain active, DFS-FCC, correct for channel 157
9. Regression within 6.18.x: Changelogs for 6.18.10→6.18.13 contain
ZERO rtw89/mac80211/cfg80211 changes. Bug exists across all 6.18.x.
== Likely Cause ==
Between kernel 6.14 and 6.18, the rtw89 driver received hundreds of commits
for WiFi 7 MLO (Multi-Link Operation) support, including:
- mac80211 per-link STA refactoring (HT/VHT/HE caps moved to per-link
link_sta structures)
- 54+ chanctx commits in rtw89 ("chan: manage active interfaces",
"tweak setting of channel and TX power for MLO", etc.)
- "disable EHT protocol by chip capabilities"
The RTL8852AE is a gen1 WiFi 6 chip. The MLO work was developed and tested
primarily on gen2 WiFi 7 chips (RTL8922A/E). It appears the gen1 code path
through the new per-link framework is not correctly populating HT/VHT/HE
capabilities during association.
== Steps to Reproduce ==
1. System with RTL8852AE (10ec:8852) running kernel 6.18.x
2. Connect to any 5 GHz 802.11ax access point
3. Observe: iw dev <if> info shows "width: 20 MHz (no HT)"
4. Observe: iw dev <if> link shows 54.0 MBit/s bitrate
5. Observe: debugfs ht/vht/he files all report "not supported"
== Expected Result ==
Connection should negotiate HT/VHT/HE (80 MHz, WiFi 6) as it did on
kernel 6.14.x, providing 800+ Mbps link rates.
Thanks,
Chris
^ permalink raw reply
* Re: 6.18.13 iwlwifi deadlock allocating cma while work-item is active.
From: Ben Greear @ 2026-03-01 15:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Korenblit, Miriam Rachel, linux-mm
In-Reply-To: <18c4bfed-caca-bef3-a139-63d7fa48940a@candelatech.com>
On 2/27/26 08:31, Ben Greear wrote:
> On 2/23/26 14:36, Ben Greear wrote:
>> Hello,
>>
>> I hit a deadlock related to CMA mem allocation attempting to flush all work
>> while holding some wifi related mutex, and with a work-queue attempting to process a wifi regdomain
>> work item. I really don't see any good way to fix this,
>> it would seem that any code that was holding a mutex that could block a work-queue
>> cannot safely allocate CMA memory? Hopefully someone else has a better idea.
>
> I tried using a kthread to do the regulatory domain processing instead of worker item,
> and that seems to have solved the problem. If that seems reasonable approach to
> wifi stack folks, I can post a patch.
The other net/wireless work-item 'disconnect_work' also needs to be moved to the kthread
for the same reason....
Thanks,
Ben
>> For whatever reason, my hacked up kernel will print out the sysrq process stack traces I need
>> to understand this, and my stable 6.18.13 will not. But, the locks-held matches in both cases, so almost
>> certainly this is same problem. I can reproduce the same problem on both un-modified stable
>> and my own. The details below are from my modified 6.18.9+ kernel.
>>
>> I only hit this (reliably?) with a KASAN enabled kernel, likely because it makes things slow enough to
>> hit the problem and/or causes CMA allocations in a different manner.
>>
>> General way to reproduce is to have large amounts of intel be200 radios in a system, and bring them
>> admin up and down.
>>
>>
>> ## From 6.18.13 (un-modified)
>>
>> 40479 Feb 23 14:13:31 ct523c-de7c kernel: 5 locks held by kworker/u32:11/34989:
>> 40480 Feb 23 14:13:31 ct523c-de7c kernel: #0: ffff888120161148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0xf7a/0x17b0
>> 40481 Feb 23 14:13:31 ct523c-de7c kernel: #1: ffff8881a561fd20 ((work_completion)(&rdev->wiphy_work)){+.+.}-{0:0}, at: process_one_work+0x7ca/0x17b0
>> 40482 Feb 23 14:13:31 ct523c-de7c kernel: #2: ffff88815e618788 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: cfg80211_wiphy_work+0x5c/0x570 [cfg80211]
>> 40483 Feb 23 14:13:31 ct523c-de7c kernel: #3: ffffffff87232e60 (&cma->alloc_mutex){+.+.}-{4:4}, at: __cma_alloc+0x3c5/0xd20
>> 40484 Feb 23 14:13:31 ct523c-de7c kernel: #4: ffffffff8534f668 (lock#5){+.+.}-{4:4}, at: __lru_add_drain_all+0x5f/0x530
>>
>> 40488 Feb 23 14:13:31 ct523c-de7c kernel: 4 locks held by kworker/1:0/39480:
>> 40489 Feb 23 14:13:31 ct523c-de7c kernel: #0: ffff88812006b148 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0xf7a/0x17b0
>> 40490 Feb 23 14:13:31 ct523c-de7c kernel: #1: ffff88814087fd20 (reg_work){+.+.}-{0:0}, at: process_one_work+0x7ca/0x17b0
>> 40491 Feb 23 14:13:31 ct523c-de7c kernel: #2: ffffffff85970028 (rtnl_mutex){+.+.}-{4:4}, at: reg_todo+0x18/0x770 [cfg80211]
>> 40492 Feb 23 14:13:31 ct523c-de7c kernel: #3: ffff88815e618788 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: reg_process_self_managed_hints+0x70/0x190 [cfg80211]
>>
>>
>> ## Rest of this is from my 6.18.9+ hacks kernel.
>>
>> ### thread trying to allocate cma is blocked here, trying to flush work.
>>
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from vmlinux...
>> (gdb) l *(alloc_contig_range_noprof+0x1de)
>> 0xffffffff8162453e is in alloc_contig_range_noprof (/home2/greearb/git/linux-6.18.dev.y/mm/page_alloc.c:6798).
>> 6793 .reason = MR_CONTIG_RANGE,
>> 6794 };
>> 6795
>> 6796 lru_cache_disable();
>> 6797
>> 6798 while (pfn < end || !list_empty(&cc->migratepages)) {
>> 6799 if (fatal_signal_pending(current)) {
>> 6800 ret = -EINTR;
>> 6801 break;
>> 6802 }
>> (gdb) l *(__lru_add_drain_all+0x19b)
>> 0xffffffff815ae44b is in __lru_add_drain_all (/home2/greearb/git/linux-6.18.dev.y/mm/swap.c:884).
>> 879 queue_work_on(cpu, mm_percpu_wq, work);
>> 880 __cpumask_set_cpu(cpu, &has_work);
>> 881 }
>> 882 }
>> 883
>> 884 for_each_cpu(cpu, &has_work)
>> 885 flush_work(&per_cpu(lru_add_drain_work, cpu));
>> 886
>> 887 done:
>> 888 mutex_unlock(&lock);
>> (gdb)
>>
>>
>> #### and other thread is trying to process a regdom request, and trying to use
>> # rcu and rtnl???
>>
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from net/wireless/cfg80211.ko...
>> (gdb) l *(reg_todo+0x18)
>> 0xe238 is in reg_todo (/home2/greearb/git/linux-6.18.dev.y/net/wireless/reg.c:3107).
>> 3102 */
>> 3103 static void reg_process_pending_hints(void)
>> 3104 {
>> 3105 struct regulatory_request *reg_request, *lr;
>> 3106
>> 3107 lr = get_last_request();
>> 3108
>> 3109 /* When last_request->processed becomes true this will be rescheduled */
>> 3110 if (lr && !lr->processed) {
>> 3111 pr_debug("Pending regulatory request, waiting for it to be processed...\n");
>> (gdb)
>>
>> static struct regulatory_request *get_last_request(void)
>> {
>> return rcu_dereference_rtnl(last_request);
>> }
>>
>>
>> task:kworker/6:0 state:D stack:0 pid:56 tgid:56 ppid:2 task_flags:0x4208060 flags:0x00080000
>> Workqueue: events reg_todo [cfg80211]
>> Call Trace:
>> <TASK>
>> __schedule+0x526/0x1290
>> preempt_schedule_notrace+0x35/0x50
>> preempt_schedule_notrace_thunk+0x16/0x30
>> rcu_is_watching+0x2a/0x30
>> lock_acquire+0x26d/0x2c0
>> schedule+0xac/0x120
>> ? schedule+0x8d/0x120
>> schedule_preempt_disabled+0x11/0x20
>> __mutex_lock+0x726/0x1070
>> ? reg_todo+0x18/0x2b0 [cfg80211]
>> ? reg_todo+0x18/0x2b0 [cfg80211]
>> reg_todo+0x18/0x2b0 [cfg80211]
>> process_one_work+0x221/0x6d0
>> worker_thread+0x1e5/0x3b0
>> ? rescuer_thread+0x450/0x450
>> kthread+0x108/0x220
>> ? kthreads_online_cpu+0x110/0x110
>> ret_from_fork+0x1c6/0x220
>> ? kthreads_online_cpu+0x110/0x110
>> ret_from_fork_asm+0x11/0x20
>> </TASK>
>>
>> task:ip state:D stack:0 pid:72857 tgid:72857 ppid:72843 task_flags:0x400100 flags:0x00080001
>> Call Trace:
>> <TASK>
>> __schedule+0x526/0x1290
>> ? schedule+0x8d/0x120
>> ? schedule+0xe2/0x120
>> schedule+0x36/0x120
>> schedule_timeout+0xf9/0x110
>> ? mark_held_locks+0x40/0x70
>> __wait_for_common+0xbe/0x1e0
>> ? hrtimer_nanosleep_restart+0x120/0x120
>> ? __flush_work+0x20b/0x530
>> __flush_work+0x34e/0x530
>> ? flush_workqueue_prep_pwqs+0x160/0x160
>> ? bpf_prog_test_run_tracing+0x160/0x2d0
>> __lru_add_drain_all+0x19b/0x220
>> alloc_contig_range_noprof+0x1de/0x8a0
>> __cma_alloc+0x1f1/0x6a0
>> __dma_direct_alloc_pages.isra.0+0xcb/0x2f0
>> dma_direct_alloc+0x7b/0x250
>> dma_alloc_attrs+0xa1/0x2a0
>> _iwl_pcie_ctxt_info_dma_alloc_coherent+0x31/0xb0 [iwlwifi]
>> iwl_pcie_ctxt_info_alloc_dma+0x20/0x50 [iwlwifi]
>> iwl_pcie_init_fw_sec+0x2fc/0x380 [iwlwifi]
>> iwl_pcie_ctxt_info_v2_alloc+0x19e/0x530 [iwlwifi]
>> iwl_trans_pcie_gen2_start_fw+0x2e2/0x820 [iwlwifi]
>> ? lock_is_held_type+0x92/0x100
>> iwl_trans_start_fw+0x77/0x90 [iwlwifi]
>> iwl_mld_load_fw_wait_alive+0x97/0x2c0 [iwlmld]
>> ? iwl_mld_mac80211_sta_state+0x780/0x780 [iwlmld]
>> ? lock_is_held_type+0x92/0x100
>> iwl_mld_load_fw+0x91/0x240 [iwlmld]
>> ? ieee80211_open+0x3d/0xe0 [mac80211]
>> ? lock_is_held_type+0x92/0x100
>> iwl_mld_start_fw+0x44/0x470 [iwlmld]
>> iwl_mld_mac80211_start+0x3d/0x1b0 [iwlmld]
>> drv_start+0x6f/0x1d0 [mac80211]
>> ieee80211_do_open+0x2d6/0x960 [mac80211]
>> ieee80211_open+0x62/0xe0 [mac80211]
>> __dev_open+0x11a/0x2e0
>> __dev_change_flags+0x1f8/0x280
>> netif_change_flags+0x22/0x60
>> do_setlink.isra.0+0xe57/0x11a0
>> ? __mutex_lock+0xb0/0x1070
>> ? __mutex_lock+0x99e/0x1070
>> ? __nla_validate_parse+0x5e/0xcd0
>> ? rtnl_newlink+0x355/0xb50
>> ? cap_capable+0x90/0x100
>> ? security_capable+0x72/0x80
>> rtnl_newlink+0x7e8/0xb50
>> ? __lock_acquire+0x436/0x2190
>> ? lock_acquire+0xc2/0x2c0
>> ? rtnetlink_rcv_msg+0x97/0x660
>> ? find_held_lock+0x2b/0x80
>> ? do_setlink.isra.0+0x11a0/0x11a0
>> ? rtnetlink_rcv_msg+0x3ea/0x660
>> ? lock_release+0xcc/0x290
>> ? do_setlink.isra.0+0x11a0/0x11a0
>> rtnetlink_rcv_msg+0x409/0x660
>> ? rtnl_fdb_dump+0x240/0x240
>> netlink_rcv_skb+0x56/0x100
>> netlink_unicast+0x1e1/0x2d0
>> netlink_sendmsg+0x219/0x460
>> __sock_sendmsg+0x38/0x70
>> ____sys_sendmsg+0x214/0x280
>> ? import_iovec+0x2c/0x30
>> ? copy_msghdr_from_user+0x6c/0xa0
>> ___sys_sendmsg+0x85/0xd0
>> ? __lock_acquire+0x436/0x2190
>> ? find_held_lock+0x2b/0x80
>> ? lock_acquire+0xc2/0x2c0
>> ? mntput_no_expire+0x43/0x460
>> ? find_held_lock+0x2b/0x80
>> ? mntput_no_expire+0x8c/0x460
>> __sys_sendmsg+0x6b/0xc0
>> do_syscall_64+0x6b/0x11b0
>> entry_SYSCALL_64_after_hwframe+0x4b/0x53
>>
>> Thanks,
>> Ben
>>
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: cfg80211: make cluster id an array
From: kernel test robot @ 2026-03-01 15:38 UTC (permalink / raw)
To: Miri Korenblit, linux-wireless; +Cc: llvm, oe-kbuild-all
In-Reply-To: <20260301131848.b0085a6b4eb3.Ib16bf5cca55463d4c89e18099cf1dfe4de95d405@changeid>
Hi Miri,
kernel test robot noticed the following build warnings:
[auto build test WARNING on wireless-next/main]
[also build test WARNING on wireless/main linus/master v7.0-rc1 next-20260227]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Miri-Korenblit/wifi-cfg80211-make-cluster-id-an-array/20260301-192010
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260301131848.b0085a6b4eb3.Ib16bf5cca55463d4c89e18099cf1dfe4de95d405%40changeid
patch subject: [PATCH wireless-next] wifi: cfg80211: make cluster id an array
config: sparc64-allmodconfig (https://download.01.org/0day-ci/archive/20260301/202603012302.fG1YckJP-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 9a109fbb6e184ec9bcce10615949f598f4c974a9)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260301/202603012302.fG1YckJP-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603012302.fG1YckJP-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/net/wireless/virtual/mac80211_hwsim.c:4081:12: warning: address of array 'conf->cluster_id' will always evaluate to 'true' [-Wpointer-bool-conversion]
4081 | if (conf->cluster_id && !is_zero_ether_addr(conf->cluster_id) &&
| ~~~~~~^~~~~~~~~~ ~~
1 warning generated.
vim +4081 drivers/net/wireless/virtual/mac80211_hwsim.c
a37a6f54439bf8 Ilan Peer 2025-09-08 4052
a37a6f54439bf8 Ilan Peer 2025-09-08 4053 static int mac80211_hwsim_start_nan(struct ieee80211_hw *hw,
a37a6f54439bf8 Ilan Peer 2025-09-08 4054 struct ieee80211_vif *vif,
a37a6f54439bf8 Ilan Peer 2025-09-08 4055 struct cfg80211_nan_conf *conf)
a37a6f54439bf8 Ilan Peer 2025-09-08 4056 {
a37a6f54439bf8 Ilan Peer 2025-09-08 4057 struct mac80211_hwsim_data *data = hw->priv;
a37a6f54439bf8 Ilan Peer 2025-09-08 4058 u64 tsf = mac80211_hwsim_get_tsf(hw, NULL);
a37a6f54439bf8 Ilan Peer 2025-09-08 4059 u32 dw_int = 512 * 1000;
a37a6f54439bf8 Ilan Peer 2025-09-08 4060 u64 until_dw = dw_int - do_div(tsf, dw_int);
a37a6f54439bf8 Ilan Peer 2025-09-08 4061 struct wireless_dev *wdev = ieee80211_vif_to_wdev(vif);
a37a6f54439bf8 Ilan Peer 2025-09-08 4062
a37a6f54439bf8 Ilan Peer 2025-09-08 4063 if (vif->type != NL80211_IFTYPE_NAN)
a37a6f54439bf8 Ilan Peer 2025-09-08 4064 return -EINVAL;
a37a6f54439bf8 Ilan Peer 2025-09-08 4065
a37a6f54439bf8 Ilan Peer 2025-09-08 4066 if (data->nan_device_vif)
a37a6f54439bf8 Ilan Peer 2025-09-08 4067 return -EALREADY;
a37a6f54439bf8 Ilan Peer 2025-09-08 4068
a37a6f54439bf8 Ilan Peer 2025-09-08 4069 /* set this before starting the timer, as preemption might occur */
a37a6f54439bf8 Ilan Peer 2025-09-08 4070 data->nan_device_vif = vif;
a37a6f54439bf8 Ilan Peer 2025-09-08 4071 data->nan_bands = conf->bands;
a37a6f54439bf8 Ilan Peer 2025-09-08 4072 data->nan_curr_dw_band = NL80211_BAND_2GHZ;
a37a6f54439bf8 Ilan Peer 2025-09-08 4073
a37a6f54439bf8 Ilan Peer 2025-09-08 4074 wiphy_debug(hw->wiphy, "nan_started, next_dw=%llu\n",
a37a6f54439bf8 Ilan Peer 2025-09-08 4075 until_dw);
a37a6f54439bf8 Ilan Peer 2025-09-08 4076
a37a6f54439bf8 Ilan Peer 2025-09-08 4077 hrtimer_start(&data->nan_timer,
a37a6f54439bf8 Ilan Peer 2025-09-08 4078 ns_to_ktime(until_dw * NSEC_PER_USEC),
a37a6f54439bf8 Ilan Peer 2025-09-08 4079 HRTIMER_MODE_REL_SOFT);
a37a6f54439bf8 Ilan Peer 2025-09-08 4080
a37a6f54439bf8 Ilan Peer 2025-09-08 @4081 if (conf->cluster_id && !is_zero_ether_addr(conf->cluster_id) &&
a37a6f54439bf8 Ilan Peer 2025-09-08 4082 is_zero_ether_addr(hwsim_nan_cluster_id)) {
a37a6f54439bf8 Ilan Peer 2025-09-08 4083 memcpy(hwsim_nan_cluster_id, conf->cluster_id, ETH_ALEN);
a37a6f54439bf8 Ilan Peer 2025-09-08 4084 } else if (is_zero_ether_addr(hwsim_nan_cluster_id)) {
a37a6f54439bf8 Ilan Peer 2025-09-08 4085 hwsim_nan_cluster_id[0] = 0x50;
a37a6f54439bf8 Ilan Peer 2025-09-08 4086 hwsim_nan_cluster_id[1] = 0x6f;
a37a6f54439bf8 Ilan Peer 2025-09-08 4087 hwsim_nan_cluster_id[2] = 0x9a;
a37a6f54439bf8 Ilan Peer 2025-09-08 4088 hwsim_nan_cluster_id[3] = 0x01;
a37a6f54439bf8 Ilan Peer 2025-09-08 4089 hwsim_nan_cluster_id[4] = get_random_u8();
a37a6f54439bf8 Ilan Peer 2025-09-08 4090 hwsim_nan_cluster_id[5] = get_random_u8();
a37a6f54439bf8 Ilan Peer 2025-09-08 4091 }
a37a6f54439bf8 Ilan Peer 2025-09-08 4092
a37a6f54439bf8 Ilan Peer 2025-09-08 4093 data->notify_dw = conf->enable_dw_notification;
a37a6f54439bf8 Ilan Peer 2025-09-08 4094
a37a6f54439bf8 Ilan Peer 2025-09-08 4095 cfg80211_nan_cluster_joined(wdev, hwsim_nan_cluster_id, true,
a37a6f54439bf8 Ilan Peer 2025-09-08 4096 GFP_KERNEL);
a37a6f54439bf8 Ilan Peer 2025-09-08 4097
a37a6f54439bf8 Ilan Peer 2025-09-08 4098 return 0;
a37a6f54439bf8 Ilan Peer 2025-09-08 4099 }
a37a6f54439bf8 Ilan Peer 2025-09-08 4100
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH wireless-next] wifi: cfg80211: make cluster id an array
From: kernel test robot @ 2026-03-01 14:26 UTC (permalink / raw)
To: Miri Korenblit, linux-wireless; +Cc: oe-kbuild-all
In-Reply-To: <20260301131848.b0085a6b4eb3.Ib16bf5cca55463d4c89e18099cf1dfe4de95d405@changeid>
Hi Miri,
kernel test robot noticed the following build warnings:
[auto build test WARNING on wireless-next/main]
[also build test WARNING on wireless/main linus/master v7.0-rc1 next-20260227]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Miri-Korenblit/wifi-cfg80211-make-cluster-id-an-array/20260301-192010
base: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git main
patch link: https://lore.kernel.org/r/20260301131848.b0085a6b4eb3.Ib16bf5cca55463d4c89e18099cf1dfe4de95d405%40changeid
patch subject: [PATCH wireless-next] wifi: cfg80211: make cluster id an array
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20260301/202603012218.ucVoRBov-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260301/202603012218.ucVoRBov-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603012218.ucVoRBov-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/wireless/virtual/mac80211_hwsim.c: In function 'mac80211_hwsim_start_nan':
>> drivers/net/wireless/virtual/mac80211_hwsim.c:4081:13: warning: the comparison will always evaluate as 'true' for the address of 'cluster_id' will never be NULL [-Waddress]
4081 | if (conf->cluster_id && !is_zero_ether_addr(conf->cluster_id) &&
| ^~~~
In file included from include/net/mac80211.h:22,
from drivers/net/wireless/virtual/mac80211_hwsim.c:22:
include/net/cfg80211.h:4038:12: note: 'cluster_id' declared here
4038 | u8 cluster_id[ETH_ALEN] __aligned(2);
| ^~~~~~~~~~
vim +4081 drivers/net/wireless/virtual/mac80211_hwsim.c
a37a6f54439bf8 Ilan Peer 2025-09-08 4052
a37a6f54439bf8 Ilan Peer 2025-09-08 4053 static int mac80211_hwsim_start_nan(struct ieee80211_hw *hw,
a37a6f54439bf8 Ilan Peer 2025-09-08 4054 struct ieee80211_vif *vif,
a37a6f54439bf8 Ilan Peer 2025-09-08 4055 struct cfg80211_nan_conf *conf)
a37a6f54439bf8 Ilan Peer 2025-09-08 4056 {
a37a6f54439bf8 Ilan Peer 2025-09-08 4057 struct mac80211_hwsim_data *data = hw->priv;
a37a6f54439bf8 Ilan Peer 2025-09-08 4058 u64 tsf = mac80211_hwsim_get_tsf(hw, NULL);
a37a6f54439bf8 Ilan Peer 2025-09-08 4059 u32 dw_int = 512 * 1000;
a37a6f54439bf8 Ilan Peer 2025-09-08 4060 u64 until_dw = dw_int - do_div(tsf, dw_int);
a37a6f54439bf8 Ilan Peer 2025-09-08 4061 struct wireless_dev *wdev = ieee80211_vif_to_wdev(vif);
a37a6f54439bf8 Ilan Peer 2025-09-08 4062
a37a6f54439bf8 Ilan Peer 2025-09-08 4063 if (vif->type != NL80211_IFTYPE_NAN)
a37a6f54439bf8 Ilan Peer 2025-09-08 4064 return -EINVAL;
a37a6f54439bf8 Ilan Peer 2025-09-08 4065
a37a6f54439bf8 Ilan Peer 2025-09-08 4066 if (data->nan_device_vif)
a37a6f54439bf8 Ilan Peer 2025-09-08 4067 return -EALREADY;
a37a6f54439bf8 Ilan Peer 2025-09-08 4068
a37a6f54439bf8 Ilan Peer 2025-09-08 4069 /* set this before starting the timer, as preemption might occur */
a37a6f54439bf8 Ilan Peer 2025-09-08 4070 data->nan_device_vif = vif;
a37a6f54439bf8 Ilan Peer 2025-09-08 4071 data->nan_bands = conf->bands;
a37a6f54439bf8 Ilan Peer 2025-09-08 4072 data->nan_curr_dw_band = NL80211_BAND_2GHZ;
a37a6f54439bf8 Ilan Peer 2025-09-08 4073
a37a6f54439bf8 Ilan Peer 2025-09-08 4074 wiphy_debug(hw->wiphy, "nan_started, next_dw=%llu\n",
a37a6f54439bf8 Ilan Peer 2025-09-08 4075 until_dw);
a37a6f54439bf8 Ilan Peer 2025-09-08 4076
a37a6f54439bf8 Ilan Peer 2025-09-08 4077 hrtimer_start(&data->nan_timer,
a37a6f54439bf8 Ilan Peer 2025-09-08 4078 ns_to_ktime(until_dw * NSEC_PER_USEC),
a37a6f54439bf8 Ilan Peer 2025-09-08 4079 HRTIMER_MODE_REL_SOFT);
a37a6f54439bf8 Ilan Peer 2025-09-08 4080
a37a6f54439bf8 Ilan Peer 2025-09-08 @4081 if (conf->cluster_id && !is_zero_ether_addr(conf->cluster_id) &&
a37a6f54439bf8 Ilan Peer 2025-09-08 4082 is_zero_ether_addr(hwsim_nan_cluster_id)) {
a37a6f54439bf8 Ilan Peer 2025-09-08 4083 memcpy(hwsim_nan_cluster_id, conf->cluster_id, ETH_ALEN);
a37a6f54439bf8 Ilan Peer 2025-09-08 4084 } else if (is_zero_ether_addr(hwsim_nan_cluster_id)) {
a37a6f54439bf8 Ilan Peer 2025-09-08 4085 hwsim_nan_cluster_id[0] = 0x50;
a37a6f54439bf8 Ilan Peer 2025-09-08 4086 hwsim_nan_cluster_id[1] = 0x6f;
a37a6f54439bf8 Ilan Peer 2025-09-08 4087 hwsim_nan_cluster_id[2] = 0x9a;
a37a6f54439bf8 Ilan Peer 2025-09-08 4088 hwsim_nan_cluster_id[3] = 0x01;
a37a6f54439bf8 Ilan Peer 2025-09-08 4089 hwsim_nan_cluster_id[4] = get_random_u8();
a37a6f54439bf8 Ilan Peer 2025-09-08 4090 hwsim_nan_cluster_id[5] = get_random_u8();
a37a6f54439bf8 Ilan Peer 2025-09-08 4091 }
a37a6f54439bf8 Ilan Peer 2025-09-08 4092
a37a6f54439bf8 Ilan Peer 2025-09-08 4093 data->notify_dw = conf->enable_dw_notification;
a37a6f54439bf8 Ilan Peer 2025-09-08 4094
a37a6f54439bf8 Ilan Peer 2025-09-08 4095 cfg80211_nan_cluster_joined(wdev, hwsim_nan_cluster_id, true,
a37a6f54439bf8 Ilan Peer 2025-09-08 4096 GFP_KERNEL);
a37a6f54439bf8 Ilan Peer 2025-09-08 4097
a37a6f54439bf8 Ilan Peer 2025-09-08 4098 return 0;
a37a6f54439bf8 Ilan Peer 2025-09-08 4099 }
a37a6f54439bf8 Ilan Peer 2025-09-08 4100
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox