* [PATCH v3 3/3] wifi: iwlwifi: mvm: replace use of system_wq with system_percpu_wq
From: Marco Crivellari @ 2026-02-10 14:33 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Marco Crivellari, Michal Hocko,
Miri Korenblit, Johannes Berg
In-Reply-To: <20260210143332.206146-1-marco.crivellari@suse.com>
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
system_wq -> system_percpu_wq
system_unbound_wq -> system_dfl_wq
This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
index 36379b738de1..0df31639fa5e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tdls.c
@@ -234,7 +234,7 @@ void iwl_mvm_rx_tdls_notif(struct iwl_mvm *mvm, struct iwl_rx_cmd_buffer *rxb)
* Also convert TU to msec.
*/
delay = TU_TO_MS(vif->bss_conf.dtim_period * vif->bss_conf.beacon_int);
- mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
+ mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
msecs_to_jiffies(delay));
iwl_mvm_tdls_update_cs_state(mvm, IWL_MVM_TDLS_SW_ACTIVE);
@@ -548,7 +548,7 @@ iwl_mvm_tdls_channel_switch(struct ieee80211_hw *hw,
*/
delay = 2 * TU_TO_MS(vif->bss_conf.dtim_period *
vif->bss_conf.beacon_int);
- mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
+ mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
msecs_to_jiffies(delay));
return 0;
}
@@ -659,6 +659,6 @@ iwl_mvm_tdls_recv_channel_switch(struct ieee80211_hw *hw,
/* register a timeout in case we don't succeed in switching */
delay = vif->bss_conf.dtim_period * vif->bss_conf.beacon_int *
1024 / 1000;
- mod_delayed_work(system_wq, &mvm->tdls_cs.dwork,
+ mod_delayed_work(system_percpu_wq, &mvm->tdls_cs.dwork,
msecs_to_jiffies(delay));
}
--
2.52.0
^ permalink raw reply related
* [PATCH v3 2/3] wifi: iwlwifi: fw: replace use of system_unbound_wq with system_dfl_wq
From: Marco Crivellari @ 2026-02-10 14:33 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Marco Crivellari, Michal Hocko,
Miri Korenblit, Johannes Berg
In-Reply-To: <20260210143332.206146-1-marco.crivellari@suse.com>
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
system_wq -> system_percpu_wq
system_unbound_wq -> system_dfl_wq
This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
index 2ce55859641c..e5f31b82339a 100644
--- a/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/fw/dbg.c
@@ -2933,7 +2933,7 @@ int iwl_fw_dbg_collect_desc(struct iwl_fw_runtime *fwrt,
IWL_WARN(fwrt, "Collecting data: trigger %d fired.\n",
le32_to_cpu(desc->trig_desc.type));
- queue_delayed_work(system_unbound_wq, &wk_data->wk,
+ queue_delayed_work(system_dfl_wq, &wk_data->wk,
usecs_to_jiffies(delay));
return 0;
@@ -3237,7 +3237,7 @@ int iwl_fw_dbg_ini_collect(struct iwl_fw_runtime *fwrt,
if (sync)
iwl_fw_dbg_collect_sync(fwrt, idx);
else
- queue_delayed_work(system_unbound_wq,
+ queue_delayed_work(system_dfl_wq,
&fwrt->dump.wks[idx].wk,
usecs_to_jiffies(delay));
--
2.52.0
^ permalink raw reply related
* [PATCH v3 1/3] wifi: iwlwifi: replace use of system_unbound_wq with system_dfl_wq
From: Marco Crivellari @ 2026-02-10 14:33 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Marco Crivellari, Michal Hocko,
Miri Korenblit, Johannes Berg
In-Reply-To: <20260210143332.206146-1-marco.crivellari@suse.com>
This patch continues the effort to refactor workqueue APIs, which has begun
with the changes introducing new workqueues and a new alloc_workqueue flag:
commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The point of the refactoring is to eventually alter the default behavior of
workqueues to become unbound by default so that their workload placement is
optimized by the scheduler.
Before that to happen after a careful review and conversion of each individual
case, workqueue users must be converted to the better named new workqueues with
no intended behaviour changes:
system_wq -> system_percpu_wq
system_unbound_wq -> system_dfl_wq
This way the old obsolete workqueues (system_wq, system_unbound_wq) can be
removed in the future.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
index a552669db6e2..2f24b639c133 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
@@ -1092,7 +1092,7 @@ static inline void iwl_trans_schedule_reset(struct iwl_trans *trans,
*/
trans->restart.during_reset = test_bit(STATUS_IN_SW_RESET,
&trans->status);
- queue_delayed_work(system_unbound_wq, &trans->restart.wk, 0);
+ queue_delayed_work(system_dfl_wq, &trans->restart.wk, 0);
}
static inline void iwl_trans_fw_error(struct iwl_trans *trans,
--
2.52.0
^ permalink raw reply related
* [PATCH v3 0/3] Replace uses of system_wq and system_unbound_wq
From: Marco Crivellari @ 2026-02-10 14:33 UTC (permalink / raw)
To: linux-kernel, linux-wireless
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Marco Crivellari, Michal Hocko,
Miri Korenblit, Johannes Berg
Hi,
=== Current situation: problems ===
Let's consider a nohz_full system with isolated CPUs: wq_unbound_cpumask is
set to the housekeeping CPUs, for !WQ_UNBOUND the local CPU is selected.
This leads to different scenarios if a work item is scheduled on an
isolated CPU where "delay" value is 0 or greater then 0:
schedule_delayed_work(, 0);
This will be handled by __queue_work() that will queue the work item on the
current local (isolated) CPU, while:
schedule_delayed_work(, 1);
Will move the timer on an housekeeping CPU, and schedule the work there.
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
=== Recent changes to the WQ API ===
The following, address the recent changes in the Workqueue API:
- commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
- commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
The old workqueues will be removed in a future release cycle.
=== Introduced Changes by this series ===
1) [P 1-2-3] Replace uses of system_unbound_wq and system_wq
Switch to using system_dfl_wq and system_percpu_wq because
system_unbound_wq and system_wq are going away
as part of a workqueue restructuring.
No intended behavior changes:
system_wq -> system_percpu_wq
Thanks!
---
Changes in v3:
- fix nvm -> mvm in patch 3 subject
- rebased on v6.19
Changes in v2:
- improved commit logs
- P3: wrong commit log was about system_unbound_wq; subject changed with
system_wq.
Marco Crivellari (3):
wifi: iwlwifi: replace use of system_unbound_wq with system_dfl_wq
wifi: iwlwifi: fw: replace use of system_unbound_wq with system_dfl_wq
wifi: iwlwifi: mvm: replace use of system_wq with system_percpu_wq
drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 4 ++--
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/tdls.c | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v2 3/3] wifi: iwlwifi: nvm: replace use of system_wq with system_percpu_wq
From: Marco Crivellari @ 2026-02-10 14:22 UTC (permalink / raw)
To: Korenblit, Miriam Rachel
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Johannes Berg
In-Reply-To: <DM3PPF63A6024A95377F0E6D202095C3349A365A@DM3PPF63A6024A9.namprd11.prod.outlook.com>
On Mon, Feb 9, 2026 at 8:59 AM Korenblit, Miriam Rachel
<miriam.rachel.korenblit@intel.com> wrote:
> Please change nvm->mvm.
> Otherwise looks good to me
> > system_percpu_wq
Hi,
Ouch, sure, I will do and submit a new version.
Thanks!
--
Marco Crivellari
L3 Support Engineer
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO
From: Johannes Berg @ 2026-02-10 13:54 UTC (permalink / raw)
To: Sai Pratyusha Magam; +Cc: linux-wireless, quic_drohan
In-Reply-To: <4a7f19a4-97bf-4dae-9020-27da3297fc68@oss.qualcomm.com>
On Tue, 2026-02-10 at 18:30 +0530, Sai Pratyusha Magam wrote:
>
> > If I restrict hwsim [1] to only pairwise and CCMP/GCMP (clearly it
> > doesn't handle TKIP due to Michael MIC, WEP is irrelevant, BIGTK isn't
> > handled in hwsim), then it mostly works without all of that extra logic
> > for me for the tests. Maybe need to think about IGTK here though, some
> > tests are still failing.
> >
> > [1] https://p.sipsolutions.net/d101bc31582cadcf.txt
> >
> Hi Johannes, Thank you for [1], yes the extra logic I had added
> (IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) to prevent offload for
> AES-CMAC/AES-GMAC, i.e, MMIE addition for beacons(BIGTK) and broadcast
> robust management frames(IGTK) and for WEP/TKIP cases was not needed and
> the correct return value in the set_key ops was all that was needed to
> selectively offload encryption for CCMP/GCMP. I missed that.
Well, you couldn't do management frames only, so in that sense the flag
IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD was needed - at minimum hwsim
also needs/needed to invoke the encrypt_tx_skb() function before address
translation for data frames.
> Today, I tried with [1] , removed the redundant logic around the
> additional key flag this patch
> introduced(IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) and data tx
> encryption offload, i.e ieee80211_encrypt_tx_skb() before address
> translation.
>
> I was able to pass the existing hwsim test cases that include test cases
> for beacon protection, broadcast robust mgmt, WEP/TKIP, unicast/bcast
> data and encrypted Assoc (EPP)
OK cool, so maybe I did something wrong in my quick attempt to figure
out if we could get away without IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD.
> > But if we do that (even if I don't like it, I'd rather fix the remaining
> > issues), then you need to document reason for it.
> >
> sorry, I did not follow this?
Sounds like we don't need IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD now,
but I meant that if we _do_ need it, the commit message should explain
why exactly.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: mac80211: Fix AAD/Nonce computation for management frames with MLO
From: Sai Pratyusha Magam @ 2026-02-10 13:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, quic_drohan
In-Reply-To: <ff9330f7e17da9c7c1ba87b9400051a9bec29aa4.camel@sipsolutions.net>
On 2/9/2026 4:57 PM, Johannes Berg wrote:
> Hi,
>
> So that looks like a huge improvement to me, nice! :-)
>
> On Sun, 2026-02-08 at 13:48 +0530, Sai Pratyusha Magam wrote:
>> The hybrid way of having both HW/driver based crypto for certain frames
>> and SW crypto for others require that the fast-xmit path be skipped
>> when the above mentioned key flag is set, since data frames still rely
>> on software based crypto
>
> I can understand this sentence in the sense of "A => B", and it
> describes why B follows from A, but ... why do you even need A? I.e. why
> do you want to do this for management frames only, it seems the encrypt
> function and having hwsim worry about it should work just as well for
> data frames?
>
> If I restrict hwsim [1] to only pairwise and CCMP/GCMP (clearly it
> doesn't handle TKIP due to Michael MIC, WEP is irrelevant, BIGTK isn't
> handled in hwsim), then it mostly works without all of that extra logic
> for me for the tests. Maybe need to think about IGTK here though, some
> tests are still failing.
>
> [1] https://p.sipsolutions.net/d101bc31582cadcf.txt
>
Hi Johannes, Thank you for [1], yes the extra logic I had added
(IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) to prevent offload for
AES-CMAC/AES-GMAC, i.e, MMIE addition for beacons(BIGTK) and broadcast
robust management frames(IGTK) and for WEP/TKIP cases was not needed and
the correct return value in the set_key ops was all that was needed to
selectively offload encryption for CCMP/GCMP. I missed that.
Today, I tried with [1] , removed the redundant logic around the
additional key flag this patch
introduced(IEEE80211_KEY_FLAG_MGMT_TX_ENC_OFFLOAD) and data tx
encryption offload, i.e ieee80211_encrypt_tx_skb() before address
translation.
I was able to pass the existing hwsim test cases that include test cases
for beacon protection, broadcast robust mgmt, WEP/TKIP, unicast/bcast
data and encrypted Assoc (EPP)
>
> But if we do that (even if I don't like it, I'd rather fix the remaining
> issues), then you need to document reason for it.
>
sorry, I did not follow this?
> johannes
^ permalink raw reply
* Re: [PATCH] wifi: mwifiex: Fix dev_alloc_name() return value check
From: Francesco Dolcini @ 2026-02-10 10:54 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Brian Norris, Francesco Dolcini, Johannes Berg, linux-wireless,
linux-kernel, Dan Carpenter
In-Reply-To: <20260210100337.1131279-1-wenst@chromium.org>
On Tue, Feb 10, 2026 at 06:03:34PM +0800, Chen-Yu Tsai wrote:
> dev_alloc_name() returns the allocated ID on success, which could be
> over 0.
>
> Fix the return value check to check for negative error codes.
>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/all/aYmsQfujoAe5qO02@stanley.mountain/
> Fixes: 7bab5bdb81e3 ("wifi: mwifiex: Allocate dev name earlier for interface workqueue name")
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
^ permalink raw reply
* Re: [PATCH wireless-next v4 3/3] wifi: mac80211_hwsim: add incumbent signal interference detection support
From: Johannes Berg @ 2026-02-10 10:36 UTC (permalink / raw)
To: Amith A; +Cc: linux-wireless, Aditya Kumar Singh
In-Reply-To: <307b4098-8154-4d83-993d-88efe38426df@oss.qualcomm.com>
On Tue, 2026-02-10 at 16:06 +0530, Amith A wrote:
>
> > > +static int hwsim_write_simulate_incumbent_signal(void *dat, u64 val)
> > > +{
> > > + struct mac80211_hwsim_data *data = dat;
> > > + struct ieee80211_chanctx_conf *chanctx_conf = NULL;
> > > +
> > > + ieee80211_iter_chan_contexts_atomic(data->hw,
> > > + hwsim_6ghz_chanctx_iter,
> > > + &chanctx_conf);
> > > +
> > > + if (!chanctx_conf)
> > > + return -EINVAL;
> > Wouldn't it make more sense require userspace to write also the
> > frequency, rather than randomly picking the first 6 GHz chandef?
> Agree. I’m currently using DEFINE_DEBUGFS_ATTRIBUTE, which only supports
> a single u64 write. To accept both frequency and bitmap, is it okay if
> define a custom fops with a .write that parses two arguments?
Ah, right, 'u64 val'.
I guess you have no choice but to define a new operation, sure :-)
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v4 3/3] wifi: mac80211_hwsim: add incumbent signal interference detection support
From: Amith A @ 2026-02-10 10:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Aditya Kumar Singh
In-Reply-To: <858522d4e40ec73197bda6a9753b2eac8c07d145.camel@sipsolutions.net>
On 2/5/2026 5:54 PM, Johannes Berg wrote:
> On Thu, 2026-02-05 at 16:51 +0530, Amith A wrote:
>> +static void hwsim_6ghz_chanctx_iter(struct ieee80211_hw *hw,
>> + struct ieee80211_chanctx_conf *conf,
>> + void *data)
>> +{
>> + struct ieee80211_chanctx_conf **out = data;
>> +
>> + if (conf->def.chan && conf->def.chan->band == NL80211_BAND_6GHZ)
>> + *out = conf;
>> +}
>> +
>> +static int hwsim_write_simulate_incumbent_signal(void *dat, u64 val)
>> +{
>> + struct mac80211_hwsim_data *data = dat;
>> + struct ieee80211_chanctx_conf *chanctx_conf = NULL;
>> +
>> + ieee80211_iter_chan_contexts_atomic(data->hw,
>> + hwsim_6ghz_chanctx_iter,
>> + &chanctx_conf);
>> +
>> + if (!chanctx_conf)
>> + return -EINVAL;
> Wouldn't it make more sense require userspace to write also the
> frequency, rather than randomly picking the first 6 GHz chandef?
Agree. I’m currently using DEFINE_DEBUGFS_ATTRIBUTE, which only supports
a single u64 write. To accept both frequency and bitmap, is it okay if
define a custom fops with a .write that parses two arguments?
>
>> +++ b/drivers/net/wireless/virtual/mac80211_hwsim.h
>> @@ -343,4 +343,6 @@ enum hwsim_rate_info_attributes {
>> HWSIM_RATE_INFO_ATTR_MAX = NUM_HWSIM_RATE_INFO_ATTRS - 1
>> };
>>
>> +/* no longer used - previously used for debugfs iterator */
> Hmm?
Will remove this in next version.
>
> johannes
^ permalink raw reply
* Re: [PATCH wireless-next v4 2/3] wifi: mac80211: add support to handle incumbent signal detected event from driver
From: Amith A @ 2026-02-10 10:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Hari Chandrakanthan, Aditya Kumar Singh
In-Reply-To: <6d5004e1e1af3f18c42c3a370db815fb4bf82b44.camel@sipsolutions.net>
On 2/5/2026 5:51 PM, Johannes Berg wrote:
> On Thu, 2026-02-05 at 16:51 +0530, Amith A wrote:
>> +void ieee80211_incumbent_signal_detected(struct ieee80211_hw *hw,
>> + struct ieee80211_chanctx_conf *chanctx_conf,
>> + u32 incumbt_sig_intf_bmap)
>> +{
>> + struct ieee80211_local *local = hw_to_local(hw);
>> +
>> + trace_api_incumbent_signal_detected(local, chanctx_conf, incumbt_sig_intf_bmap);
>> + cfg80211_incumbent_signal_notify(hw->wiphy,
>> + &chanctx_conf->def,
>> + incumbt_sig_intf_bmap,
>> + GFP_ATOMIC);
>> +}
>> +EXPORT_SYMBOL(ieee80211_incumbent_signal_detected);
> There's nothing here that couldn't be done directly by the driver
> (except tracing), do we even need this indirection? Caller could just
> call cfg80211 directly, no?
Will remove this in the next version and have the driver call the
cfg80211 API directly
>
> johannes
^ permalink raw reply
* Re: [PATCH wireless-next v4 1/3] wifi: cfg80211: add support to handle incumbent signal detected event from mac80211/driver
From: Amith A @ 2026-02-10 10:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Hari Chandrakanthan
In-Reply-To: <f28034e35e7b1e9c942de3b78a8b03de9e2833cb.camel@sipsolutions.net>
On 2/5/2026 5:52 PM, Johannes Berg wrote:
> On Thu, 2026-02-05 at 16:51 +0530, Amith A wrote:
>> +++ b/include/net/cfg80211.h
>> @@ -10423,4 +10423,27 @@ cfg80211_s1g_get_primary_sibling(struct wiphy *wiphy,
>> return ieee80211_get_channel_khz(wiphy, sibling_1mhz_khz);
>> }
>>
>> +
>> +/**
>> + * cfg80211_incumbent_signal_notify - Notify userspace of incumbent signal detection
>> + * @wiphy: the wiphy to use
>> + * @chandef: channel definition in which the interference was detected
>> + * @signal_interference_bitmap: bitmap indicating interference across 20 MHz segments
>> + * @gfp: allocation context for message creation and multicast; pass GFP_ATOMIC
>> + * if called from atomic context (e.g. firmware event handler), otherwise
>> + * GFP_KERNEL
>> + *
>> + * Use this function to notify userspace when an incumbent signal is detected on
>> + * the operating channel in the 6 GHz band. The notification includes the
>> + * current channel definition and a bitmap representing interference across
>> + * the operating bandwidth. Each bit in the bitmap corresponds to a 20 MHz
>> + * segment, with the lowest bit representing the lowest frequency segment.
>> + * Punctured sub-channels are included in the bitmap structure but are always
>> + * set to zero since interference detection is not performed on them.
>> + */
>> +void cfg80211_incumbent_signal_notify(struct wiphy *wiphy,
>> + struct cfg80211_chan_def *chandef,
> chandef could be const, I guess?
Will update in next version
>
> johannes
^ permalink raw reply
* [PATCH] wifi: mwifiex: Fix dev_alloc_name() return value check
From: Chen-Yu Tsai @ 2026-02-10 10:03 UTC (permalink / raw)
To: Brian Norris, Francesco Dolcini, Johannes Berg
Cc: Chen-Yu Tsai, linux-wireless, linux-kernel, Dan Carpenter
dev_alloc_name() returns the allocated ID on success, which could be
over 0.
Fix the return value check to check for negative error codes.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/all/aYmsQfujoAe5qO02@stanley.mountain/
Fixes: 7bab5bdb81e3 ("wifi: mwifiex: Allocate dev name earlier for interface workqueue name")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index a66d18e380fc..bc0a946e8e6e 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3148,7 +3148,7 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
SET_NETDEV_DEV(dev, adapter->dev);
ret = dev_alloc_name(dev, name);
- if (ret)
+ if (ret < 0)
goto err_alloc_name;
priv->dfs_cac_workqueue = alloc_workqueue("MWIFIEX_DFS_CAC-%s",
--
2.53.0.rc2.204.g2597b5adb4-goog
^ permalink raw reply related
* RE: [PATCH v2] net: intel: fix PCI device ID conflict between i40e and ipw2200
From: Loktionov, Aleksandr @ 2026-02-10 7:11 UTC (permalink / raw)
To: Ethan Nelson-Moore, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org
Cc: stable@vger.kernel.org, Johannes Berg, Nguyen, Anthony L,
Kitszel, Przemyslaw, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Stanislav Yakovlev, Alice Michael
In-Reply-To: <20260210021235.16315-1-enelsonmoore@gmail.com>
> -----Original Message-----
> From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> Sent: Tuesday, February 10, 2026 3:13 AM
> To: netdev@vger.kernel.org; linux-wireless@vger.kernel.org
> Cc: Ethan Nelson-Moore <enelsonmoore@gmail.com>;
> stable@vger.kernel.org; Johannes Berg <johannes@sipsolutions.net>;
> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Stanislav Yakovlev <stas.yakovlev@gmail.com>;
> Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Alice Michael
> <alice.michael@intel.com>
> Subject: [PATCH v2] net: intel: fix PCI device ID conflict between
> i40e and ipw2200
>
> The ID 8086:104f is matched by both i40e and ipw2200. The same device
> ID should not be in more than one driver, because in that case, which
> driver is used is unpredictable. Fix this by taking advantage of the
> fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
> devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices.
>
> Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards")
> Cc: stable@vger.kernel.org
> Acked-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> Changes from v1:
> Rebase on latest mainline instead of net-next
>
> drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +++++++-
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 +++++++-
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index d3bc3207054f..02de186dcc8f 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -75,7 +75,13 @@ static const struct pci_device_id i40e_pci_tbl[] =
> {
> {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T4), 0},
> {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T_BC), 0},
> {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_SFP), 0},
> - {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_B), 0},
> + /*
> + * This ID conflicts with ipw2200, but the devices can be
> differentiated
> + * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and
> ipw2200
> + * devices use PCI_CLASS_NETWORK_OTHER.
> + */
> + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_B),
> + PCI_CLASS_NETWORK_ETHERNET << 8, 0xffff00, 0},
> {PCI_VDEVICE(INTEL, I40E_DEV_ID_KX_X722), 0},
> {PCI_VDEVICE(INTEL, I40E_DEV_ID_QSFP_X722), 0},
> {PCI_VDEVICE(INTEL, I40E_DEV_ID_SFP_X722), 0}, diff --git
> a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> index 09035a77e775..b0e769da9415 100644
> --- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
> @@ -11387,7 +11387,13 @@ static const struct pci_device_id card_ids[]
> = {
> {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2754, 0, 0, 0},
> {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2761, 0, 0, 0},
> {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2762, 0, 0, 0},
> - {PCI_VDEVICE(INTEL, 0x104f), 0},
> + /*
> + * This ID conflicts with i40e, but the devices can be
> differentiated
> + * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and
> ipw2200
> + * devices use PCI_CLASS_NETWORK_OTHER.
> + */
> + {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x104f),
> + PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, 0},
> {PCI_VDEVICE(INTEL, 0x4220), 0}, /* BG */
> {PCI_VDEVICE(INTEL, 0x4221), 0}, /* BG */
> {PCI_VDEVICE(INTEL, 0x4223), 0}, /* ABG */
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: fix backoff fields and max_power calculation
From: Sven Eckelmann @ 2026-02-10 7:01 UTC (permalink / raw)
To: robh@kernel.org, Ryder Lee
Cc: linux-wireless@vger.kernel.org, nbd@nbd.name,
linux-mediatek@lists.infradead.org,
Allen Ye (葉芷勳), saravanak@kernel.org
In-Reply-To: <1816591a2149629822a1e08fc4c3fe7601b802fa.camel@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
On Tuesday, 10 February 2026 07:38:24 CET Ryder Lee wrote:
> Of course, I can revise the description for connac3. I just wanted to
> say that there’s no need to change the min and max values, which should
> make things much simpler.
Ok, thanks
Regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* RE: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips
From: Ping-Ke Shih @ 2026-02-10 6:44 UTC (permalink / raw)
To: Bitterblue Smith, linux-wireless@vger.kernel.org
In-Reply-To: <a95d43dc-58c7-4c9c-9b42-204f2134f099@gmail.com>
Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 09/02/2026 10:19, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> When connected to a network in the 2.4 GHz band, wpa_supplicant (or
> >> NetworkManager?) triggers a scan every five minutes. During these scans
> >> mac80211 transmits many QoS Null frames in quick succession. Because
> >> these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
> >> asks the firmware to report the TX ACK status for each of these frames.
> >> Sometimes the firmware can't process the TX status requests quickly
> >> enough, they add up, it only processes some of them, and then marks
> >> every subsequent TX status report with the wrong number.
> >
> > Does it mean number of reports is correct? But with incorrect sequence number?
> > Then, you just ignore checking 'sn' but assume 'st' is correct.
> >
>
> The number of reports is correct most of the time. Only when the firmware
> is overwhelmed (?) it doesn't provide every report, but later it recovers.
>
I was not aware that this happened while scanning, so we might apply this loose
checking under scan condition -- test_bit(RTW_FLAG_SCANNING, rtwdev->flags)"?
If TX report is because of re-key, it can still use original rule.
[...]
>
> >>
> >> The symptom is that after a while the warning "failed to get tx report
> >> from firmware" appears every five minutes.
> >>
> >> This problem apparently happens only with the older RTL8723D, RTL8821A,
> >> RTL8812A, and probably RTL8703B chips. Ignore the TX report sequence
> >> number reported by these chips and match the reports with the requests
> >> in the order they come in.
> >>
> >> Tested with RTL8821AU and RTL8723DU.
> >>
> >> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
> >> ---
> >> drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
> >> index c04ff31d0f1e..98215ecc884a 100644
> >> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> >> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> >> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
> >> spin_lock_irqsave(&tx_report->q_lock, flags);
> >> skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
> >> n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
> >> - if (*n == sn) {
> >> + if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
> >
> > Can we only limit to USB devices (or non-PCI devices)?
> >
>
> I don't think so. RTL8821AE also has this problem. I didn't mention it
> in the commit message because support for RTL8821AE in rtw88 is
> unofficial. (I modified rtw88_pci to handle the older generation, see
> the use_new_trx_flow=false code path in rtlwifi.)
How about official RTL8723DE?
>
> >> __skb_unlink(cur, &tx_report->queue);
> >> rtw_tx_report_tx_status(rtwdev, cur, st == 0);
> >> break;
> >> --
> >> 2.52.0
> >
^ permalink raw reply
* Re: [PATCH v2] wifi: mt76: fix backoff fields and max_power calculation
From: Ryder Lee @ 2026-02-10 6:38 UTC (permalink / raw)
To: robh@kernel.org, sven@narfation.org
Cc: linux-wireless@vger.kernel.org, nbd@nbd.name,
linux-mediatek@lists.infradead.org,
Allen Ye (葉芷勳), saravanak@kernel.org
In-Reply-To: <4713788.LvFx2qVVIh@ripper>
On Mon, 2026-02-09 at 10:17 +0100, Sven Eckelmann wrote:
> On Monday, 9 February 2026 08:48:50 CET Ryder Lee wrote:
> > - In connac2, beamforming entries for BW20~BW160 and OFDM do not
> > include 1T1ss.
> > - In connac3, beamforming entries for BW20~BW160 and RU include
> > 1T1ss,
> > but OFDM beamforming does not include 1T1ss.
>
> This doesn't seem to match the documentation [1]:
>
> paths-ofdm-bf:
> $ref: /schemas/types.yaml#/definitions/uint8-
> array
> minItems: 4
> maxItems: 4
> description:
> 4 half-dBm backoff values for beamforming
> (1 - 4 antennas, single spacial stream)
> ...
> paths-ru-bf:
> $ref: /schemas/types.yaml#/definitions/uint8-
> matrix
> description:
> Sets of half-dBm backoff (beamforming) values
> for 802.11ax
> rates for 1T1ss (aka 1 transmitting antenna
> with 1 spacial
> stream), 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss,
> 4T2ss, 3T3ss,
> 4T3ss and 4T4ss.
> Each set starts with the number of channel
> bandwidth or
> resource unit settings for which the rate set
> applies,
> followed by 10 power limit values. The order of
> the
> channel resource unit settings is RU26, RU52,
> RU106,
> RU242/SU20, RU484/SU40, RU996/SU80 and
> RU2x996/SU160.
> minItems: 1
> maxItems: 7
> items:
> minItems: 11
> maxItems: 11
>
> Regards,
> Sven
>
> [1]
> https://www.kernel.org/doc/Documentation/devicetree/bindings/net/wireless/mediatek%2Cmt76.yaml
Hmm...If we really want to dig it out, this document is indeed not
precise enough.
This is for the 7915 when filling in the Bw20/40/80/160 power values.
In mt7915_mcu_set_txpower_sku()
....
for (i = 0; i < 8; i++) {
bool bf = i % 2;
u8 idx = (i + 6) / 2;
s8 *buf = bf ? la.path.ru_bf[idx] : la.path.ru[idx];
/* The non-bf fields of RU26 to RU106 are special cases
*/
if (bf)
skb_put_data(skb, buf + 1, 9);
else
skb_put_data(skb, buf, 10);
}
The skb order is filled according to the firmware requirements.
Each field corresponds to: 1T1ss, 2T1ss, 3T1ss, 4T1ss, 2T2ss, 3T2ss,
4T2ss, 3T3ss, 4T3ss, and 4T4ss, for a total of 10 values.
For beamform case, mt76 does not need to fill in the value for 1T1ss,
so the length is 9.
For non-beamform case, mt76 needs to fill in the value for 1T1ss, so
the length is 10.
The DTS still needs to provide 1 + 10 because mt76 does not
specifically check for this when parsing DTS.
So a connac2 DTS would be filled like this:
paths-ru-bf =
<1 20 22 38 36 24 30 23 21 28 29>,
<1 20 39 31 25 26 25 28 30 39 39>,
<1 37 34 26 26 25 21 34 23 34 24>,
<1 0 20 23 31 23 30 39 28 29 36>,
<1 0 27 34 33 34 29 38 33 33 22>,
<1 0 30 23 39 28 21 25 29 28 21>,
<1 0 34 20 38 32 35 33 37 26 36>;
When 1T1ss is not used, it should be filled with 0. For connac3, since
1T1ss is taken into account, we don’t need to fill it with 0.
The unused 1T1ss still needs to be written in the DTS. This is to make
parsing easier.
So the number indicated in the current document is correct; it’s just
that the description isn’t precise enough.
Of course, I can revise the description for connac3. I just wanted to
say that there’s no need to change the min and max values, which should
make things much simpler.
Ryder
^ permalink raw reply
* Re: [PATCH ath-next 2/4] wifi: ath12k: avoid long fw_stats waits on vdev stats hot path
From: Baochen Qiang @ 2026-02-10 5:31 UTC (permalink / raw)
To: m.limarencko, jjohnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260209030243.1530075-3-m.limarencko@yandex.ru>
On 2/9/2026 11:02 AM, m.limarencko@yandex.ru wrote:
> From: Mikhail Limarenko <m.limarencko@yandex.ru>
>
> Station info requests can trigger frequent VDEV stat pulls from
>
> user space (iw/NM polling).
>
> On affected firmware, waiting 3 seconds for fw_stats_done causes
>
> repeated stalls and visible hitches.
>
> Use a short timeout for VDEV_STAT requests and skip unnecessary
>
> waits for stats types that do not need completion
>
> synchronization.
can you please try
https://lore.kernel.org/ath12k/20260129-ath12k-fw-stats-fixes-v1-0-55d66064f4d5@oss.qualcomm.com/
>
> Tested-on: QCNFA765 (WCN785x), kernel 6.18.5+deb13-amd64
> Signed-off-by: Mikhail Limarenko <m.limarencko@yandex.ru>
> ---
> drivers/net/wireless/ath/ath12k/mac.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> index 095b49a..1b550e9 100644
> --- a/drivers/net/wireless/ath/ath12k/mac.c
> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> @@ -4829,6 +4829,7 @@ int ath12k_mac_get_fw_stats(struct ath12k *ar,
> {
> struct ath12k_base *ab = ar->ab;
> struct ath12k_hw *ah = ath12k_ar_to_ah(ar);
> + unsigned long done_timeout = 3 * HZ;
> unsigned long time_left;
> int ret;
>
> @@ -4859,15 +4860,32 @@ int ath12k_mac_get_fw_stats(struct ath12k *ar,
> return -ETIMEDOUT;
> }
>
> + /* VDEV stats are queried frequently from station info paths (e.g. iw/NM).
> + * On buggy firmware this path can timeout repeatedly and block callers for
> + * multiple seconds; keep the hot path responsive while preserving behavior
> + * for other stats types.
> + */
> + if (param->stats_id & WMI_REQUEST_VDEV_STAT)
> + done_timeout = msecs_to_jiffies(200);
> +
> + /* Non-vdev/bcn stats are handled in a single event. */
> + if (!(param->stats_id & (WMI_REQUEST_VDEV_STAT | WMI_REQUEST_BCN_STAT)))
> + return 0;
> +
> /* Firmware sends WMI_UPDATE_STATS_EVENTID back-to-back
> * when stats data buffer limit is reached. fw_stats_complete
> * is completed once host receives first event from firmware, but
> * still there could be more events following. Below is to wait
> * until firmware completes sending all the events.
> */
> - time_left = wait_for_completion_timeout(&ar->fw_stats_done, 3 * HZ);
> + time_left = wait_for_completion_timeout(&ar->fw_stats_done, done_timeout);
> if (!time_left) {
> - ath12k_warn(ab, "time out while waiting for fw stats done\n");
> + if (param->stats_id & WMI_REQUEST_VDEV_STAT)
> + ath12k_dbg(ab, ATH12K_DBG_WMI,
> + "time out while waiting for fw stats done (stats_id 0x%x)\n",
> + param->stats_id);
> + else
> + ath12k_warn(ab, "time out while waiting for fw stats done\n");
> return -ETIMEDOUT;
> }
>
^ permalink raw reply
* Re: [PATCH ath-next 1/4] wifi: ath12k: validate survey index when frequency is not found
From: Baochen Qiang @ 2026-02-10 3:37 UTC (permalink / raw)
To: m.limarencko, jjohnson; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260209030243.1530075-2-m.limarencko@yandex.ru>
On 2/9/2026 11:02 AM, m.limarencko@yandex.ru wrote:
> From: Mikhail Limarenko <m.limarencko@yandex.ru>
>
> freq_to_idx() currently returns a monotonic index even when the
>
> frequency was never matched.
>
> In chan info paths this can lead to out-of-bounds survey indexing
how can out-of-bound index happen? there is already the ARRAY_SIZE(ar->survey) check there
to prevent this, no?
>
> for unexpected frequency events.
>
> Return -EINVAL on no match and make callers reject negative
>
> indexes.
>
> Tested-on: QCNFA765 (WCN785x), kernel 6.18.5+deb13-amd64
> Signed-off-by: Mikhail Limarenko <m.limarencko@yandex.ru>
> ---
> drivers/net/wireless/ath/ath12k/wmi.c | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
> index e647b84..422e3f8 100644
> --- a/drivers/net/wireless/ath/ath12k/wmi.c
> +++ b/drivers/net/wireless/ath/ath12k/wmi.c
> @@ -6520,7 +6520,7 @@ static int freq_to_idx(struct ath12k *ar, int freq)
> if (!sband)
> continue;
>
> - for (ch = 0; ch < sband->n_channels; ch++, idx++) {
> + for (ch = 0; ch < sband->n_channels; ch++) {
> if (sband->channels[ch].center_freq <
> KHZ_TO_MHZ(ar->freq_range.start_freq) ||
> sband->channels[ch].center_freq >
> @@ -6528,12 +6528,13 @@ static int freq_to_idx(struct ath12k *ar, int freq)
> continue;
>
> if (sband->channels[ch].center_freq == freq)
> - goto exit;
> + return idx;
> +
> + idx++;
> }
> }
>
> -exit:
> - return idx;
> + return -EINVAL;
> }
>
> static int ath12k_pull_chan_info_ev(struct ath12k_base *ab, struct sk_buff *skb,
> @@ -7475,7 +7476,7 @@ static void ath12k_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
> }
>
> idx = freq_to_idx(ar, le32_to_cpu(ch_info_ev.freq));
> - if (idx >= ARRAY_SIZE(ar->survey)) {
> + if (idx < 0 || idx >= ARRAY_SIZE(ar->survey)) {
> ath12k_warn(ab, "chan info: invalid frequency %d (idx %d out of bounds)\n",
> ch_info_ev.freq, idx);
> goto exit;
> @@ -7550,7 +7551,7 @@ ath12k_pdev_bss_chan_info_event(struct ath12k_base *ab, struct sk_buff *skb)
>
> spin_lock_bh(&ar->data_lock);
> idx = freq_to_idx(ar, le32_to_cpu(bss_ch_info_ev.freq));
> - if (idx >= ARRAY_SIZE(ar->survey)) {
> + if (idx < 0 || idx >= ARRAY_SIZE(ar->survey)) {
> ath12k_warn(ab, "bss chan info: invalid frequency %d (idx %d out of bounds)\n",
> bss_ch_info_ev.freq, idx);
> goto exit;
^ permalink raw reply
* Re: [PATCH ath-current] wifi: ath12k: fix incorrect channel survey index
From: Baochen Qiang @ 2026-02-10 3:23 UTC (permalink / raw)
To: Yingying Tang, ath12k; +Cc: linux-wireless, yintang
In-Reply-To: <20260210024440.3422264-1-yingying.tang@oss.qualcomm.com>
On 2/10/2026 10:44 AM, Yingying Tang wrote:
> A wrong channel survey index was introduced in
> ath12k_mac_op_get_survey by [1], which can cause ACS to fail.
>
> The index is decremented before being used, resulting in an
> incorrect value when accessing the channel survey data.
>
> Fix the index handling to ensure the correct survey entry is
> used and avoid ACS failures.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
>
> Fixes: 4f242b1d6996 ("wifi: ath12k: support get_survey mac op for single wiphy") # [1]
> Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
>
> ---
> drivers/net/wireless/ath/ath12k/mac.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
> index e0e49f782bf8..86ce7d87b5a5 100644
> --- a/drivers/net/wireless/ath/ath12k/mac.c
> +++ b/drivers/net/wireless/ath/ath12k/mac.c
> @@ -13086,6 +13086,7 @@ static int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,
> struct ath12k *ar;
> struct ieee80211_supported_band *sband;
> struct survey_info *ar_survey;
> + int orig_idx = idx;
>
> lockdep_assert_wiphy(hw->wiphy);
>
> @@ -13120,7 +13121,7 @@ static int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,
> return -ENOENT;
> }
>
> - ar_survey = &ar->survey[idx];
> + ar_survey = &ar->survey[orig_idx];
>
> ath12k_mac_update_bss_chan_survey(ar, &sband->channels[idx]);
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
>
^ permalink raw reply
* [PATCH ath-current] wifi: ath12k: prepare REO update element only for primary link
From: Baochen Qiang @ 2026-02-10 3:07 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath12k, linux-kernel, Baochen Qiang
Commit [1] introduces dp->reo_cmd_update_rx_queue_list for the purpose
of tracking all pending REO queue flush commands. The helper
ath12k_dp_prepare_reo_update_elem() allocates an element and populates
it with REO queue information, then add it to the list. The element would
be helpful during clean up stage to finally unmap/free the corresponding
REO queue buffer.
In MLO scenarios with more than one links, for non dp_primary_link_only
chips like WCN7850, that helper is called for each link peer. This
results in multiple elements added to the list but all of them pointing
to the same REO queue buffer. Consequently the same buffer gets
unmap/freed multiple times:
BUG kmalloc-2k (Tainted: G B W O ): Object already free
-----------------------------------------------------------------------------
Allocated in ath12k_wifi7_dp_rx_assign_reoq+0xce/0x280 [ath12k_wifi7] age=7436 cpu=10 pid=16130
__kmalloc_noprof
ath12k_wifi7_dp_rx_assign_reoq
ath12k_dp_rx_peer_tid_setup
ath12k_dp_peer_setup
ath12k_mac_station_add
ath12k_mac_op_sta_state
[...]
Freed in ath12k_dp_rx_tid_cleanup.part.0+0x25/0x40 [ath12k] age=1 cpu=27 pid=16137
kfree
ath12k_dp_rx_tid_cleanup.part.0
ath12k_dp_rx_reo_cmd_list_cleanup
ath12k_dp_cmn_device_deinit
ath12k_core_stop
ath12k_core_hw_group_cleanup
ath12k_pci_remove
Fix this by allowing list addition for primary link only. Note
dp_primary_link_only chips like QCN9274 are not affected by this change,
because that's what they were doing in the first place.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 3bf2e57e7d6c ("wifi: ath12k: Add Retry Mechanism for REO RX Queue Update Failures") # [1]
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221011
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/dp_rx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/dp_rx.c b/drivers/net/wireless/ath/ath12k/dp_rx.c
index a32ee9f8061a..6995de7761df 100644
--- a/drivers/net/wireless/ath/ath12k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath12k/dp_rx.c
@@ -565,6 +565,9 @@ static int ath12k_dp_prepare_reo_update_elem(struct ath12k_dp *dp,
lockdep_assert_held(&dp->dp_lock);
+ if (!peer->primary_link)
+ return 0;
+
elem = kzalloc(sizeof(*elem), GFP_ATOMIC);
if (!elem)
return -ENOMEM;
---
base-commit: d9a2be2d72d4f9035f0334e0ff49180fe9df6e52
change-id: 20260128-ath12k-rxtid-double-free-289100bb5163
Best regards,
--
Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v2] wifi: mt76: mt7921: fix txpower reporting
From: Nick @ 2026-02-10 3:02 UTC (permalink / raw)
To: Lucid Duck; +Cc: nbd, lorenzo, linux-wireless
In-Reply-To: <20260130215458.52886-1-lucid_duck@justthetip.ca>
> The mt7921 driver never updates phy->txpower_cur, causing
> mt76_get_txpower() to report incorrect values via nl80211.
> Users see bogus txpower readings (typically 3 dBm or 67 dBm)
> regardless of actual regulatory limits.
>
> Fix this by updating txpower_cur in mt7921_bss_info_changed()
> when BSS_CHANGED_TXPOWER is set. Use bss_conf.txpower as the
> primary source, with a fallback to the channel's max_reg_power
> for cases where bss_conf.txpower is not populated (INT_MIN).
>
> Tested on Alfa AWUS036AXML (MT7921AU), kernel 6.18.6:
> - 2.4GHz ch1: 33 dBm (30 dBm limit + 3 dBm path delta) - PASS
> - 5GHz ch100: 27 dBm (24 dBm limit + 3 dBm path delta) - PASS
> - 6GHz ch5: 15 dBm (12 dBm limit + 3 dBm path delta) - PASS
I just tested this patch with a fresh download of kernel 6.18.8. All I
see is 3 dBm
when running "iw dev". My USB WiFi adapter also uses the mt7921u driver.
Also, something just doesn't seem right with 33, 27 and 15 dBm. You are in CA,
right?
> Signed-off-by: Lucid Duck <lucid_duck@justthetip.ca>
> ---
> drivers/net/wireless/mediatek/mt76/mt7921/main.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/main.c b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> index f37a35b..99fe46d 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/main.c
> @@ -725,6 +725,25 @@ static void mt7921_bss_info_changed(struct ieee80211_hw *hw,
> if (changed & BSS_CHANGED_CQM)
> mt7921_mcu_set_rssimonitor(dev, vif);
>
> + if (changed & BSS_CHANGED_TXPOWER) {
> + int tx_power = info->txpower;
> +
> + /*
> + * Workaround for kernel 6.18+: bss_conf.txpower may not be
> + * populated (INT_MIN) even when BSS_CHANGED_TXPOWER is set.
> + * In this case, use the channel's max regulatory power.
> + */
> + if (tx_power == INT_MIN || tx_power <= 0) {
> + struct ieee80211_channel *chan = phy->mt76->chandef.chan;
> + if (chan)
> + tx_power = chan->max_reg_power;
> + }
> +
> + /* txpower is in dBm, txpower_cur is in 0.5dBm units */
> + if (tx_power > 0 && tx_power < 127)
> + phy->mt76->txpower_cur = tx_power * 2;
> + }
> +
> if (changed & BSS_CHANGED_ASSOC) {
> mt7921_mcu_sta_update(dev, NULL, vif, true,
> MT76_STA_INFO_STATE_ASSOC);
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH ath-current] wifi: ath12k: fix incorrect channel survey index
From: Yingying Tang @ 2026-02-10 2:44 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, yintang, yingying.tang
A wrong channel survey index was introduced in
ath12k_mac_op_get_survey by [1], which can cause ACS to fail.
The index is decremented before being used, resulting in an
incorrect value when accessing the channel survey data.
Fix the index handling to ensure the correct survey entry is
used and avoid ACS failures.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 4f242b1d6996 ("wifi: ath12k: support get_survey mac op for single wiphy") # [1]
Signed-off-by: Yingying Tang <yingying.tang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/mac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index e0e49f782bf8..86ce7d87b5a5 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -13086,6 +13086,7 @@ static int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,
struct ath12k *ar;
struct ieee80211_supported_band *sband;
struct survey_info *ar_survey;
+ int orig_idx = idx;
lockdep_assert_wiphy(hw->wiphy);
@@ -13120,7 +13121,7 @@ static int ath12k_mac_op_get_survey(struct ieee80211_hw *hw, int idx,
return -ENOENT;
}
- ar_survey = &ar->survey[idx];
+ ar_survey = &ar->survey[orig_idx];
ath12k_mac_update_bss_chan_survey(ar, &sband->channels[idx]);
--
base-commit: 1cac38910ecb881b09f61f57545a771bbe57ba68
^ permalink raw reply related
* [PATCH v2] net: intel: fix PCI device ID conflict between i40e and ipw2200
From: Ethan Nelson-Moore @ 2026-02-10 2:12 UTC (permalink / raw)
To: netdev, linux-wireless
Cc: Ethan Nelson-Moore, stable, Johannes Berg, Tony Nguyen,
Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Stanislav Yakovlev,
Aleksandr Loktionov, Alice Michael
The ID 8086:104f is matched by both i40e and ipw2200. The same device
ID should not be in more than one driver, because in that case, which
driver is used is unpredictable. Fix this by taking advantage of the
fact that i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
devices use PCI_CLASS_NETWORK_OTHER to differentiate the devices.
Fixes: 2e45d3f4677a ("i40e: Add support for X710 B/P & SFP+ cards")
Cc: stable@vger.kernel.org
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Changes from v1:
Rebase on latest mainline instead of net-next
drivers/net/ethernet/intel/i40e/i40e_main.c | 8 +++++++-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 8 +++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index d3bc3207054f..02de186dcc8f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -75,7 +75,13 @@ static const struct pci_device_id i40e_pci_tbl[] = {
{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T4), 0},
{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_BASE_T_BC), 0},
{PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_SFP), 0},
- {PCI_VDEVICE(INTEL, I40E_DEV_ID_10G_B), 0},
+ /*
+ * This ID conflicts with ipw2200, but the devices can be differentiated
+ * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
+ * devices use PCI_CLASS_NETWORK_OTHER.
+ */
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, I40E_DEV_ID_10G_B),
+ PCI_CLASS_NETWORK_ETHERNET << 8, 0xffff00, 0},
{PCI_VDEVICE(INTEL, I40E_DEV_ID_KX_X722), 0},
{PCI_VDEVICE(INTEL, I40E_DEV_ID_QSFP_X722), 0},
{PCI_VDEVICE(INTEL, I40E_DEV_ID_SFP_X722), 0},
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 09035a77e775..b0e769da9415 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -11387,7 +11387,13 @@ static const struct pci_device_id card_ids[] = {
{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2754, 0, 0, 0},
{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2761, 0, 0, 0},
{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2762, 0, 0, 0},
- {PCI_VDEVICE(INTEL, 0x104f), 0},
+ /*
+ * This ID conflicts with i40e, but the devices can be differentiated
+ * because i40e devices use PCI_CLASS_NETWORK_ETHERNET and ipw2200
+ * devices use PCI_CLASS_NETWORK_OTHER.
+ */
+ {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x104f),
+ PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, 0},
{PCI_VDEVICE(INTEL, 0x4220), 0}, /* BG */
{PCI_VDEVICE(INTEL, 0x4221), 0}, /* BG */
{PCI_VDEVICE(INTEL, 0x4223), 0}, /* ABG */
--
2.43.0
^ permalink raw reply related
* [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY
From: Richard Acayan @ 2026-02-10 2:12 UTC (permalink / raw)
To: Jeff Johnson, Michal Kazior, Kalle Valo, linux-wireless, ath10k
Cc: Richard Acayan
In-Reply-To: <20260210021249.12132-1-mailingradian@gmail.com>
When sending DELETE_KEY, the driver times out waiting for a response
that doesn't come. Only wait for a response when sending SET_KEY.
Sample dmesg:
[ 117.285854] wlan0: deauthenticating from XX:XX:XX:XX:XX:XX by local choice (Reason: 3=DEAUTH_LEAVING)
[ 120.302934] ath10k_snoc 18800000.wifi: failed to install key for vdev 0 peer XX:XX:XX:XX:XX:XX: -110
[ 120.302996] wlan0: failed to remove key (0, XX:XX:XX:XX:XX:XX) from hardware (-110)
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index da6f7957a0ae..73aa93043f8a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -324,9 +324,11 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
if (ret)
return ret;
- time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
- if (time_left == 0)
- return -ETIMEDOUT;
+ if (cmd != DISABLE_KEY) {
+ time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
+ if (time_left == 0)
+ return -ETIMEDOUT;
+ }
return 0;
}
--
2.53.0
^ permalink raw reply related
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