* Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
From: Johannes Berg @ 2026-04-22 19:06 UTC (permalink / raw)
To: Tristan Madani, Brian Norris; +Cc: linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <20260421134938.331334-4-tristmd@gmail.com>
On Tue, 2026-04-21 at 13:49 +0000, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The firmware-controlled sta_count (u16) is used as an unbounded loop
> counter for iterating station info entries. An inflated count drives
> reads past the response buffer into kernel heap memory.
>
> Add a check that sta_count fits within the response size.
>
> Fixes: b21783e94e20 ("mwifiex: add sta_list firmware command")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> Changes in v3:
> - Regenerated from wireless-next with proper git format-patch to
> produce valid index hashes (v2 had post-processed index lines).
For the record, that wasn't the problem. I _think_ the problem was that
your post-processing also skipped whitespace-only lines, which are very
relevant in patches.
johannes
^ permalink raw reply
* Re: [PATCH v2] wifi: ath12k: fix false positive RCU warnings on PREEMPT_RT
From: 曾昱翔 @ 2026-04-22 18:29 UTC (permalink / raw)
To: Jeff Johnson
Cc: Jeff Johnson, ath12k, Baochen Qiang, Rameshkumar Sundaram,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
linux-wireless, linux-kernel, linux-rt-devel
In-Reply-To: <5209fd4c-eee3-46ed-b731-1e822a04b03b@oss.qualcomm.com>
On Wed, Apr 22, 2026 at 06:33:45 -0700, Jeff Johnson wrote:
> Amended patch in my pending branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=32f70ee38388bb9089b9cffa9791f5ef8d5d32cd
Thanks for picking it up and fixing the Tested-on placement.
Sebastian pointed out on v2 that the fix should use
lockdep_assert_in_rcu_read_lock() rather than RCU_LOCKDEP_WARN(),
since the former is gated on CONFIG_PROVE_RCU (same effect) but
expresses the intent more precisely. He also noted that the bug
is not PREEMPT_RT specific but applies to preemptible RCU in
general.
I've sent v3 addressing both points:
https://lore.kernel.org/ath12k/20260422180814.1938317-1-asas1asas200@gmail.com/
Let me know if you'd like me to do anything further.
Thanks,
Yu-Hsiang
Jeff Johnson <jeff.johnson@oss.qualcomm.com> 於 2026年4月22日週三 下午9:33寫道：
>
> On 4/21/2026 2:27 PM, Jeff Johnson wrote:
> > On 4/21/2026 10:25 AM, Yu-Hsiang Tseng wrote:
> >> Two functions in ath12k assert that the caller holds an RCU read lock:
> >> ath12k_mac_get_arvif() and ath12k_p2p_noa_update_vdev_iter(). Both use:
> >>
> >> WARN_ON(!rcu_read_lock_any_held());
> >>
> >> On PREEMPT_RT kernels built with CONFIG_PROVE_RCU=n, this produces a
> >> false positive splat whenever these functions are invoked from paths
> >> that do hold the RCU read lock (e.g. firmware stats processing or
> >> mac80211 interface iteration).
> >>
> >> Root cause:
> >>
> >> - On !PROVE_RCU, rcu_read_lock_any_held() is a static inline that
> >> returns !preemptible() as a proxy for "in an RCU read section".
> >>
> >> - On PREEMPT_RT, rcu_read_lock() does not disable preemption. A
> >> task can therefore be preemptible while legitimately holding an
> >> RCU read lock.
> >>
> >> - Callers such as ath12k_wmi_tlv_rssi_chain_parse() (via guard(rcu)())
> >> and ieee80211_iterate_active_interfaces_atomic() do hold the RCU
> >> read lock, so these warnings are incorrect.
> >>
> >> Typical splat seen on a WCN7850 station with periodic fw stats
> >> processing:
> >>
> >> WARNING: drivers/net/wireless/ath/ath12k/mac.c:791 at
> >> ath12k_mac_get_arvif+0x9e/0xd0 [ath12k]
> >> Tainted: G W O 6.19.13-rt #1 PREEMPT_RT
> >> Call Trace:
> >> ath12k_wmi_tlv_rssi_chain_parse+0x69/0x170 [ath12k]
> >> ath12k_wmi_tlv_iter+0x7f/0x120 [ath12k]
> >> ath12k_wmi_tlv_fw_stats_parse+0x342/0x6b0 [ath12k]
> >> ath12k_wmi_op_rx+0xe9e/0x3150 [ath12k]
> >> ath12k_htc_rx_completion_handler+0x3df/0x5b0 [ath12k]
> >> ath12k_ce_per_engine_service+0x325/0x3e0 [ath12k]
> >> ath12k_pci_ce_workqueue+0x20/0x40 [ath12k]
> >>
> >> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
> >> debug_lockdep_rcu_enabled() and therefore compiles out entirely
> >> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
> >> full lockdep-based check.
> >>
> >> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
> >> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
> >
> > Note that Tested-on: is not a official upstream tag, it is an ath-specific
> > tag. Since it is not an official tag, it should be specified separately from
> > the official tags:
> >
> > <commit text>
> > <blank line>
> > Tested-on: ...
> > <blank line>
> > <official upstream tags>
> > Signed-off-by: ...
> >
> > Unless there are are other review comments there is no need to send a v3 to
> > address this -- I can make this change when I pick up the patch.
> Amended patch in my pending branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=32f70ee38388bb9089b9cffa9791f5ef8d5d32cd
^ permalink raw reply
* Re: [PATCH v3 4/6] wifi: mwifiex: fix OOB read in scan response from mismatched TLV data sizes
From: Brian Norris @ 2026-04-22 18:28 UTC (permalink / raw)
To: Tristan Madani
Cc: Johannes Berg, linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <20260421134938.331334-5-tristmd@gmail.com>
On Tue, Apr 21, 2026 at 01:49:36PM +0000, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The TSF and ChanBand TLV arrays are indexed by the firmware-controlled
> number_of_sets without cross-checking against the TLV header length
> fields. When number_of_sets exceeds the TLV data, the loop reads past
> the TLV data into adjacent command response memory.
>
> Stop using the TLV data once the index exceeds its reported length.
>
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> Changes in v3:
> - Regenerated from wireless-next with proper git format-patch to
> produce valid index hashes (v2 had post-processed index lines).
>
> Changes in v2:
> - No code changes from v1.
>
> drivers/net/wireless/marvell/mwifiex/scan.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
My brain cries a little every time I have to read and trust this sort of
arithmetic in C.
Acked-by: Brian Norris <briannorris@chromium.org>
^ permalink raw reply
* Re: [PATCH v3 3/6] wifi: mwifiex: fix OOB read from firmware sta_count in station list response
From: Brian Norris @ 2026-04-22 18:26 UTC (permalink / raw)
To: Tristan Madani
Cc: Johannes Berg, linux-wireless, linux-kernel, Tristan Madani
In-Reply-To: <20260421134938.331334-4-tristmd@gmail.com>
On Tue, Apr 21, 2026 at 01:49:35PM +0000, Tristan Madani wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> The firmware-controlled sta_count (u16) is used as an unbounded loop
> counter for iterating station info entries. An inflated count drives
> reads past the response buffer into kernel heap memory.
>
> Add a check that sta_count fits within the response size.
>
> Fixes: b21783e94e20 ("mwifiex: add sta_list firmware command")
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> Changes in v3:
> - Regenerated from wireless-next with proper git format-patch to
> produce valid index hashes (v2 had post-processed index lines).
>
> Changes in v2:
> - No code changes from v1.
>
> drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
> index 85512f526c5f2..4cf654046c6ae 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
> @@ -976,8 +976,16 @@ static int mwifiex_ret_uap_sta_list(struct mwifiex_private *priv,
> struct mwifiex_ie_types_sta_info *sta_info = (void *)&sta_list->tlv;
> int i;
> struct mwifiex_sta_node *sta_node;
> + u16 resp_size = le16_to_cpu(resp->size);
> + u16 count = le16_to_cpu(sta_list->sta_count);
> + u16 max_count;
>
> - for (i = 0; i < (le16_to_cpu(sta_list->sta_count)); i++) {
> + if (resp_size < sizeof(*resp) - sizeof(resp->params) + sizeof(*sta_list))
> + return -EINVAL;
> + max_count = (resp_size - sizeof(*resp) + sizeof(resp->params) -
> + sizeof(*sta_list)) / sizeof(*sta_info);
The repeated arithmetic is a bit weird, but I'm not sure if it'd
actually be better to stash it in its own variable. Seems good enough I
suppose.
Acked-by: Brian Norris <briannorris@chromium.org>
> + count = min(count, max_count);
> + for (i = 0; i < count; i++) {
> sta_node = mwifiex_get_sta_entry(priv, sta_info->mac);
> if (unlikely(!sta_node))
> continue;
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2] wifi: ath12k: fix false positive RCU warnings on PREEMPT_RT
From: Yu-Hsiang Tseng @ 2026-04-22 18:12 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Jeff Johnson, ath12k, Baochen Qiang, Rameshkumar Sundaram,
Kalle Valo, Clark Williams, Steven Rostedt, linux-wireless,
linux-kernel, linux-rt-devel
In-Reply-To: <20260422142325.Glnd_2Zc@linutronix.de>
On Wed, Apr 22, 2026 at 04:23:25PM +0200, Sebastian Andrzej Siewior wrote:
> As elaborated above, this is not PREEMPT_RT specific but preemptible
> TREE RCU.
You're right. Sent v3 that clarifies the scope (preemptible RCU in
general, not only PREEMPT_RT).
> If both this then use this then I guess something like
> lockdep_assert_in_rcu_read_lock()
> is what you look for.
Adopted in v3 - thanks for the pointer, it reads much cleaner than
RCU_LOCKDEP_WARN().
v3: https://lore.kernel.org/ath12k/20260422180814.1938317-1-asas1asas200@gmail.com/
Thanks,
Yu-Hsiang
^ permalink raw reply
* [PATCH v3] wifi: ath12k: use lockdep_assert_in_rcu_read_lock() for RCU assertions
From: Yu-Hsiang Tseng @ 2026-04-22 18:08 UTC (permalink / raw)
To: Jeff Johnson, ath12k
Cc: Baochen Qiang, Rameshkumar Sundaram, Kalle Valo,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
linux-wireless, linux-kernel, linux-rt-devel
Two functions in ath12k assert that the caller holds an RCU read lock:
ath12k_mac_get_arvif() and ath12k_p2p_noa_update_vdev_iter(). Both use:
WARN_ON(!rcu_read_lock_any_held());
On kernels using preemptible RCU (CONFIG_PREEMPT=y or CONFIG_PREEMPT_RT=y)
without CONFIG_DEBUG_LOCK_ALLOC, this produces a false positive splat
whenever these functions are invoked from paths that do hold the RCU
read lock (e.g. firmware stats processing or mac80211 interface
iteration).
Root cause:
- Without CONFIG_DEBUG_LOCK_ALLOC, rcu_read_lock_any_held() is a
static inline that returns !preemptible() as a proxy for "in an
RCU read section".
- With preemptible RCU, rcu_read_lock() does not disable preemption.
A task can therefore be preemptible while legitimately holding an
RCU read lock, making the proxy unreliable.
- Callers such as ath12k_wmi_tlv_rssi_chain_parse() (via guard(rcu)())
and ieee80211_iterate_active_interfaces_atomic() do hold the RCU
read lock, so these warnings are incorrect.
Typical splat seen on a WCN7850 station with periodic fw stats
processing:
WARNING: drivers/net/wireless/ath/ath12k/mac.c:791 at
ath12k_mac_get_arvif+0x9e/0xd0 [ath12k]
Tainted: G W O 6.19.13-rt #1 PREEMPT_RT
Call Trace:
ath12k_wmi_tlv_rssi_chain_parse+0x69/0x170 [ath12k]
ath12k_wmi_tlv_iter+0x7f/0x120 [ath12k]
ath12k_wmi_tlv_fw_stats_parse+0x342/0x6b0 [ath12k]
ath12k_wmi_op_rx+0xe9e/0x3150 [ath12k]
ath12k_htc_rx_completion_handler+0x3df/0x5b0 [ath12k]
ath12k_ce_per_engine_service+0x325/0x3e0 [ath12k]
ath12k_pci_ce_workqueue+0x20/0x40 [ath12k]
Replace WARN_ON(!rcu_read_lock_any_held()) with
lockdep_assert_in_rcu_read_lock(), which is gated on CONFIG_PROVE_RCU
and therefore compiles out entirely when PROVE_RCU is disabled.
PROVE_RCU kernels continue to get the full lockdep-based check, and
the new helper precisely checks for rcu_read_lock() rather than any
RCU variant, which better matches the callers' expectations.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
Suggested-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Signed-off-by: Yu-Hsiang Tseng <asas1asas200@gmail.com>
---
Changes in v3:
- Use lockdep_assert_in_rcu_read_lock() instead of RCU_LOCKDEP_WARN()
for clearer intent and more precise semantics (suggested by
Sebastian Andrzej Siewior)
- Reword commit message: this affects preemptible RCU in general,
not only PREEMPT_RT
- Move Tested-on before the official tags per ath convention
Changes in v2:
- Also fix the same WARN_ON() in ath12k_p2p_noa_update_vdev_iter()
(suggested by Baochen Qiang)
- Update commit message to cover both call sites
Link to v1: https://lore.kernel.org/ath12k/20260420161049.695518-1-asas1asas200@gmail.com/
Link to v2: https://lore.kernel.org/ath12k/20260421172500.1050754-1-asas1asas200@gmail.com/
drivers/net/wireless/ath/ath12k/mac.c | 2 +-
drivers/net/wireless/ath/ath12k/p2p.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index fbdfe6424fd7..df2334f3bad6 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -788,7 +788,7 @@ struct ath12k_link_vif *ath12k_mac_get_arvif(struct ath12k *ar, u32 vdev_id)
/* To use the arvif returned, caller must have held rcu read lock.
*/
- WARN_ON(!rcu_read_lock_any_held());
+ lockdep_assert_in_rcu_read_lock();
arvif_iter.vdev_id = vdev_id;
arvif_iter.ar = ar;
diff --git a/drivers/net/wireless/ath/ath12k/p2p.c b/drivers/net/wireless/ath/ath12k/p2p.c
index 59589748f1a8..19ebcd1d8eb2 100644
--- a/drivers/net/wireless/ath/ath12k/p2p.c
+++ b/drivers/net/wireless/ath/ath12k/p2p.c
@@ -123,7 +123,7 @@ static void ath12k_p2p_noa_update_vdev_iter(void *data, u8 *mac,
struct ath12k_p2p_noa_arg *arg = data;
struct ath12k_link_vif *arvif;
- WARN_ON(!rcu_read_lock_any_held());
+ lockdep_assert_in_rcu_read_lock();
arvif = &ahvif->deflink;
if (!arvif->is_created || arvif->ar != arg->ar || arvif->vdev_id != arg->vdev_id)
return;
--
2.53.0
^ permalink raw reply related
* [PATCH] wifi: rsi: fix kthread lifetime race between self-exit and external-stop
From: Jeongjun Park @ 2026-04-22 17:38 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo
Cc: linux-wireless, linux-kernel, syzbot+5de83f57cd8531f55596, stable,
Jeongjun Park
RSI driver use both self-exit(kthread_complete_and_exit) and external-stop
(kthread_stop) when killing a kthread. Generally, kthread_stop() is called
first, and in this case, no particular issues occur.
However, in rare instances where kthread_complete_and_exit() is called
first and then kthread_stop() is called, a UAF occurs because the kthread
object, which has already exited and been freed, is accessed again.
Therefore, to prevent this with minimal modification, you must remove
kthread_stop() and change the code to wait until the self-exit operation
is completed.
Cc: <stable@vger.kernel.org>
Reported-by: syzbot+5de83f57cd8531f55596@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69e5d03b.a00a0220.1bd0ca.0064.GAE@google.com/
Fixes: 4c62764d0fc2 ("rsi: improve kernel thread handling to fix kernel panic")
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
---
drivers/net/wireless/rsi/rsi_common.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_common.h b/drivers/net/wireless/rsi/rsi_common.h
index 591602beeec6..3cdf9ded876d 100644
--- a/drivers/net/wireless/rsi/rsi_common.h
+++ b/drivers/net/wireless/rsi/rsi_common.h
@@ -70,12 +70,11 @@ static inline int rsi_create_kthread(struct rsi_common *common,
return 0;
}
-static inline int rsi_kill_thread(struct rsi_thread *handle)
+static inline void rsi_kill_thread(struct rsi_thread *handle)
{
atomic_inc(&handle->thread_done);
rsi_set_event(&handle->event);
-
- return kthread_stop(handle->task);
+ wait_for_completion(&handle->completion);
}
void rsi_mac80211_detach(struct rsi_hw *hw);
--
^ permalink raw reply related
* [PATCH ath] wifi: ath12k: fix leak in some ath12k_wmi_xxx() functions
From: Nicolas Escande @ 2026-04-22 16:32 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
Some wmi functions were using plain 'return ath12k_wmi_cmd_send(...)'
without explicitly handling the error code. This leads to leaking the skb
in case of error.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00218-QCAHKSWPL_SILICONZ-1
Fixes: 66a9448b1b89 ("wifi: ath12k: implement hardware data filter")
Fixes: 593174170919 ("wifi: ath12k: implement WoW enable and wakeup commands")
Fixes: 4a3c212eee0e ("wifi: ath12k: add basic WoW functionalities")
Fixes: 16f474d6d49d ("wifi: ath12k: add WoW net-detect functionality")
Fixes: 1666108c74c4 ("wifi: ath12k: support ARP and NS offload")
Fixes: aab4ae566fa1 ("wifi: ath12k: support GTK rekey offload")
Fixes: 7af01e569529 ("wifi: ath12k: handle keepalive during WoWLAN suspend and resume")
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
drivers/net/wireless/ath/ath12k/wmi.c | 103 ++++++++++++++++++++++----
1 file changed, 88 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 65a05a9520ff..75c87edd2a8a 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -10251,7 +10251,7 @@ int ath12k_wmi_hw_data_filter_cmd(struct ath12k *ar, struct wmi_hw_data_filter_a
{
struct wmi_hw_data_filter_cmd *cmd;
struct sk_buff *skb;
- int len;
+ int ret, len;
len = sizeof(*cmd);
skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -10275,7 +10275,13 @@ int ath12k_wmi_hw_data_filter_cmd(struct ath12k *ar, struct wmi_hw_data_filter_a
"wmi hw data filter enable %d filter_bitmap 0x%x\n",
arg->enable, arg->hw_filter_bitmap);
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_HW_DATA_FILTER_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_HW_DATA_FILTER_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_HW_DATA_FILTER_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_wow_host_wakeup_ind(struct ath12k *ar)
@@ -10283,6 +10289,7 @@ int ath12k_wmi_wow_host_wakeup_ind(struct ath12k *ar)
struct wmi_wow_host_wakeup_cmd *cmd;
struct sk_buff *skb;
size_t len;
+ int ret;
len = sizeof(*cmd);
skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -10295,14 +10302,20 @@ int ath12k_wmi_wow_host_wakeup_ind(struct ath12k *ar)
ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow host wakeup ind\n");
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_WOW_HOSTWAKEUP_FROM_SLEEP_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_wow_enable(struct ath12k *ar)
{
struct wmi_wow_enable_cmd *cmd;
struct sk_buff *skb;
- int len;
+ int ret, len;
len = sizeof(*cmd);
skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -10317,7 +10330,13 @@ int ath12k_wmi_wow_enable(struct ath12k *ar)
cmd->pause_iface_config = cpu_to_le32(WOW_IFACE_PAUSE_ENABLED);
ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow enable\n");
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_WOW_ENABLE_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_wow_add_wakeup_event(struct ath12k *ar, u32 vdev_id,
@@ -10327,6 +10346,7 @@ int ath12k_wmi_wow_add_wakeup_event(struct ath12k *ar, u32 vdev_id,
struct wmi_wow_add_del_event_cmd *cmd;
struct sk_buff *skb;
size_t len;
+ int ret;
len = sizeof(*cmd);
skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -10343,7 +10363,13 @@ int ath12k_wmi_wow_add_wakeup_event(struct ath12k *ar, u32 vdev_id,
ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow add wakeup event %s enable %d vdev_id %d\n",
wow_wakeup_event(event), enable, vdev_id);
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_WOW_ENABLE_DISABLE_WAKE_EVENT_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_wow_add_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id,
@@ -10356,6 +10382,7 @@ int ath12k_wmi_wow_add_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id,
struct sk_buff *skb;
void *ptr;
size_t len;
+ int ret;
len = sizeof(*cmd) +
sizeof(*tlv) + /* array struct */
@@ -10435,7 +10462,13 @@ int ath12k_wmi_wow_add_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id,
ath12k_dbg_dump(ar->ab, ATH12K_DBG_WMI, NULL, "wow bitmask: ",
bitmap->bitmaskbuf, pattern_len);
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ADD_WAKE_PATTERN_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_ADD_WAKE_PATTERN_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_WOW_ADD_WAKE_PATTERN_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_wow_del_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id)
@@ -10443,6 +10476,7 @@ int ath12k_wmi_wow_del_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id)
struct wmi_wow_del_pattern_cmd *cmd;
struct sk_buff *skb;
size_t len;
+ int ret;
len = sizeof(*cmd);
skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -10459,7 +10493,13 @@ int ath12k_wmi_wow_del_pattern(struct ath12k *ar, u32 vdev_id, u32 pattern_id)
ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "wmi tlv wow del pattern vdev_id %d pattern_id %d\n",
vdev_id, pattern_id);
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_DEL_WAKE_PATTERN_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_WOW_DEL_WAKE_PATTERN_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_WOW_DEL_WAKE_PATTERN_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
static struct sk_buff *
@@ -10595,6 +10635,7 @@ int ath12k_wmi_wow_config_pno(struct ath12k *ar, u32 vdev_id,
struct wmi_pno_scan_req_arg *pno_scan)
{
struct sk_buff *skb;
+ int ret;
if (pno_scan->enable)
skb = ath12k_wmi_op_gen_config_pno_start(ar, vdev_id, pno_scan);
@@ -10604,7 +10645,13 @@ int ath12k_wmi_wow_config_pno(struct ath12k *ar, u32 vdev_id,
if (IS_ERR_OR_NULL(skb))
return -ENOMEM;
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_NETWORK_LIST_OFFLOAD_CONFIG_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_NETWORK_LIST_OFFLOAD_CONFIG_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_NETWORK_LIST_OFFLOAD_CONFIG_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
static void ath12k_wmi_fill_ns_offload(struct ath12k *ar,
@@ -10717,6 +10764,7 @@ int ath12k_wmi_arp_ns_offload(struct ath12k *ar,
void *buf_ptr;
size_t len;
u8 ns_cnt, ns_ext_tuples = 0;
+ int ret;
ns_cnt = offload->ipv6_count;
@@ -10752,7 +10800,13 @@ int ath12k_wmi_arp_ns_offload(struct ath12k *ar,
if (ns_ext_tuples)
ath12k_wmi_fill_ns_offload(ar, offload, &buf_ptr, enable, 1);
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_SET_ARP_NS_OFFLOAD_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_SET_ARP_NS_OFFLOAD_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_SET_ARP_NS_OFFLOAD_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_gtk_rekey_offload(struct ath12k *ar,
@@ -10762,7 +10816,7 @@ int ath12k_wmi_gtk_rekey_offload(struct ath12k *ar,
struct wmi_gtk_rekey_offload_cmd *cmd;
struct sk_buff *skb;
__le64 replay_ctr;
- int len;
+ int ret, len;
len = sizeof(*cmd);
skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -10789,7 +10843,13 @@ int ath12k_wmi_gtk_rekey_offload(struct ath12k *ar,
ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "offload gtk rekey vdev: %d %d\n",
arvif->vdev_id, enable);
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_GTK_OFFLOAD_CMDID offload\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_gtk_rekey_getinfo(struct ath12k *ar,
@@ -10797,7 +10857,7 @@ int ath12k_wmi_gtk_rekey_getinfo(struct ath12k *ar,
{
struct wmi_gtk_rekey_offload_cmd *cmd;
struct sk_buff *skb;
- int len;
+ int ret, len;
len = sizeof(*cmd);
skb = ath12k_wmi_alloc_skb(ar->wmi->wmi_ab, len);
@@ -10811,7 +10871,13 @@ int ath12k_wmi_gtk_rekey_getinfo(struct ath12k *ar,
ath12k_dbg(ar->ab, ATH12K_DBG_WMI, "get gtk rekey vdev_id: %d\n",
arvif->vdev_id);
- return ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
+ ret = ath12k_wmi_cmd_send(ar->wmi, skb, WMI_GTK_OFFLOAD_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_GTK_OFFLOAD_CMDID getinfo\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_sta_keepalive(struct ath12k *ar,
@@ -10822,6 +10888,7 @@ int ath12k_wmi_sta_keepalive(struct ath12k *ar,
struct wmi_sta_keepalive_cmd *cmd;
struct sk_buff *skb;
size_t len;
+ int ret;
len = sizeof(*cmd) + sizeof(*arp);
skb = ath12k_wmi_alloc_skb(wmi->wmi_ab, len);
@@ -10849,7 +10916,13 @@ int ath12k_wmi_sta_keepalive(struct ath12k *ar,
"wmi sta keepalive vdev %d enabled %d method %d interval %d\n",
arg->vdev_id, arg->enabled, arg->method, arg->interval);
- return ath12k_wmi_cmd_send(wmi, skb, WMI_STA_KEEPALIVE_CMDID);
+ ret = ath12k_wmi_cmd_send(wmi, skb, WMI_STA_KEEPALIVE_CMDID);
+ if (ret) {
+ ath12k_warn(ar->ab, "failed to send WMI_STA_KEEPALIVE_CMDID\n");
+ dev_kfree_skb(skb);
+ }
+
+ return ret;
}
int ath12k_wmi_mlo_setup(struct ath12k *ar, struct wmi_mlo_setup_arg *mlo_params)
--
2.53.0
^ permalink raw reply related
* [PATCH ath-next] wifi: ath12k: unify error handling in some ath12k_wmi_xxx() functions
From: Nicolas Escande @ 2026-04-22 16:32 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless
This is purely cosmetic changes that simplifies & standardizes error
handling for functions that ends with a ath12k_wmi_cmd_send() followed
by trivial error handling. Saves a few lines of code too.
Compile tested only.
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
drivers/net/wireless/ath/ath12k/wmi.c | 32 +++++++--------------------
1 file changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/wmi.c b/drivers/net/wireless/ath/ath12k/wmi.c
index 350f249f5ba6..bfe4af76304c 100644
--- a/drivers/net/wireless/ath/ath12k/wmi.c
+++ b/drivers/net/wireless/ath/ath12k/wmi.c
@@ -4199,12 +4199,9 @@ int ath12k_wmi_pdev_lro_cfg(struct ath12k *ar,
if (ret) {
ath12k_warn(ar->ab,
"failed to send lro cfg req wmi cmd\n");
- goto err;
+ dev_kfree_skb(skb);
}
- return 0;
-err:
- dev_kfree_skb(skb);
return ret;
}
@@ -4335,12 +4332,9 @@ int ath12k_wmi_vdev_spectral_conf(struct ath12k *ar,
if (ret) {
ath12k_warn(ar->ab,
"failed to send spectral scan config wmi cmd\n");
- goto err;
+ dev_kfree_skb(skb);
}
- return 0;
-err:
- dev_kfree_skb(skb);
return ret;
}
@@ -4372,12 +4366,9 @@ int ath12k_wmi_vdev_spectral_enable(struct ath12k *ar, u32 vdev_id,
if (ret) {
ath12k_warn(ar->ab,
"failed to send spectral enable wmi cmd\n");
- goto err;
+ dev_kfree_skb(skb);
}
- return 0;
-err:
- dev_kfree_skb(skb);
return ret;
}
@@ -4418,12 +4409,9 @@ int ath12k_wmi_pdev_dma_ring_cfg(struct ath12k *ar,
if (ret) {
ath12k_warn(ar->ab,
"failed to send dma ring cfg req wmi cmd\n");
- goto err;
+ dev_kfree_skb(skb);
}
- return 0;
-err:
- dev_kfree_skb(skb);
return ret;
}
@@ -10874,10 +10862,9 @@ int ath12k_wmi_mlo_setup(struct ath12k *ar, struct wmi_mlo_setup_arg *mlo_params
ath12k_warn(ar->ab, "failed to submit WMI_MLO_SETUP_CMDID command: %d\n",
ret);
dev_kfree_skb(skb);
- return ret;
}
- return 0;
+ return ret;
}
int ath12k_wmi_mlo_ready(struct ath12k *ar)
@@ -10902,10 +10889,9 @@ int ath12k_wmi_mlo_ready(struct ath12k *ar)
ath12k_warn(ar->ab, "failed to submit WMI_MLO_READY_CMDID command: %d\n",
ret);
dev_kfree_skb(skb);
- return ret;
}
- return 0;
+ return ret;
}
int ath12k_wmi_mlo_teardown(struct ath12k *ar)
@@ -10931,10 +10917,9 @@ int ath12k_wmi_mlo_teardown(struct ath12k *ar)
ath12k_warn(ar->ab, "failed to submit WMI MLO teardown command: %d\n",
ret);
dev_kfree_skb(skb);
- return ret;
}
- return 0;
+ return ret;
}
bool ath12k_wmi_supports_6ghz_cc_ext(struct ath12k *ar)
@@ -10997,10 +10982,9 @@ int ath12k_wmi_send_vdev_set_tpc_power(struct ath12k *ar,
if (ret) {
ath12k_warn(ar->ab, "failed to send WMI_VDEV_SET_TPC_POWER_CMDID\n");
dev_kfree_skb(skb);
- return ret;
}
- return 0;
+ return ret;
}
static int
--
2.53.0
^ permalink raw reply related
* Re: [PATCH ath-current] wifi: ath12k: prepare REO update element only for primary link
From: Jeff Johnson @ 2026-04-22 14:34 UTC (permalink / raw)
To: Thorsten Leemhuis, Baochen Qiang, Jeff Johnson
Cc: linux-wireless, ath12k, linux-kernel,
Linux kernel regressions list
In-Reply-To: <ed0ecf21-54b4-41e0-92a9-3c7a0e140882@leemhuis.info>
On 4/22/2026 2:30 AM, Thorsten Leemhuis wrote:
> Lo! Top-posting on purpose to make this easy to process.
>
> Jeff, what happened to below patch? It was supposed to fix the
> regression linked below, but unless I'm missing something (which might
> very well be the case!) it seems it never got any further than this thread.
>
> Ciao, Thorsten
>
> P.S:: Adding a stable tag might be good to ensure this fix is backported.
No, I dropped the ball on this. Let me pick it up for next week's -rc2
/jeff
^ permalink raw reply
* Re: [PATCH v2] wifi: ath12k: fix false positive RCU warnings on PREEMPT_RT
From: Sebastian Andrzej Siewior @ 2026-04-22 14:23 UTC (permalink / raw)
To: Yu-Hsiang Tseng
Cc: Jeff Johnson, ath12k, Baochen Qiang, Rameshkumar Sundaram,
Kalle Valo, Clark Williams, Steven Rostedt, linux-wireless,
linux-kernel, linux-rt-devel
In-Reply-To: <20260421172500.1050754-1-asas1asas200@gmail.com>
On 2026-04-22 01:25:00 [+0800], Yu-Hsiang Tseng wrote:
> Two functions in ath12k assert that the caller holds an RCU read lock:
> ath12k_mac_get_arvif() and ath12k_p2p_noa_update_vdev_iter(). Both use:
>
> WARN_ON(!rcu_read_lock_any_held());
>
> On PREEMPT_RT kernels built with CONFIG_PROVE_RCU=n, this produces a
> false positive splat whenever these functions are invoked from paths
> that do hold the RCU read lock (e.g. firmware stats processing or
> mac80211 interface iteration).
It depends what RCU section is expected/ tested for. SMP+preempt can use
preemptible RCU which does not disable preemption either. So this is not
PREEMPT_RT specific. It would be PREEMPT_RT specific if the RCU section
is implied by NAPI processing to so.
> Root cause:
>
> - On !PROVE_RCU, rcu_read_lock_any_held() is a static inline that
> returns !preemptible() as a proxy for "in an RCU read section".
>
> - On PREEMPT_RT, rcu_read_lock() does not disable preemption. A
> task can therefore be preemptible while legitimately holding an
> RCU read lock.
As elaborated above, this is not PREEMPT_RT specific but preemptible
TREE RCU.
> - Callers such as ath12k_wmi_tlv_rssi_chain_parse() (via guard(rcu)())
> and ieee80211_iterate_active_interfaces_atomic() do hold the RCU
> read lock, so these warnings are incorrect.
If both this then use this then I guess something like
lockdep_assert_in_rcu_read_lock()
is what you look for.
> Typical splat seen on a WCN7850 station with periodic fw stats
> processing:
>
> WARNING: drivers/net/wireless/ath/ath12k/mac.c:791 at
> ath12k_mac_get_arvif+0x9e/0xd0 [ath12k]
> Tainted: G W O 6.19.13-rt #1 PREEMPT_RT
> Call Trace:
> ath12k_wmi_tlv_rssi_chain_parse+0x69/0x170 [ath12k]
> ath12k_wmi_tlv_iter+0x7f/0x120 [ath12k]
> ath12k_wmi_tlv_fw_stats_parse+0x342/0x6b0 [ath12k]
> ath12k_wmi_op_rx+0xe9e/0x3150 [ath12k]
> ath12k_htc_rx_completion_handler+0x3df/0x5b0 [ath12k]
> ath12k_ce_per_engine_service+0x325/0x3e0 [ath12k]
> ath12k_pci_ce_workqueue+0x20/0x40 [ath12k]
If that is the call chain and there are no spinlocks involved then
PREEMPT+SMP+lockdep should trigger with this patch, too. The suggestion
above restricts this to lockdep only but your patch does so to.
Sebastian
^ permalink raw reply
* Re: [PATCH v6] wifi: ath9k: Obtain system GPIOS from descriptors
From: Jeff Johnson @ 2026-04-22 13:59 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann, Alban Bedel, Bartosz Golaszewski,
Toke Høiland-Jørgensen, Michał Kępień,
Linus Walleij
Cc: linux-wireless, brcm80211-dev-list.pdl, linux-gpio,
Bartosz Golaszewski
In-Reply-To: <20260317-descriptors-wireless-v6-1-b19ecff9cd2b@kernel.org>
On Tue, 17 Mar 2026 09:45:20 +0100, Linus Walleij wrote:
> The ath9k has an odd use of system-wide GPIOs: if the chip
> does not have internal GPIO capability, it will try to obtain a
> GPIO line from the system GPIO controller:
>
> if (BIT(gpio) & ah->caps.gpio_mask)
> ath9k_hw_gpio_cfg_wmac(...);
> else if (AR_SREV_SOC(ah))
> ath9k_hw_gpio_cfg_soc(ah, gpio, out, label);
>
> [...]
Applied, thanks!
[1/1] wifi: ath9k: Obtain system GPIOS from descriptors
commit: 34a5329beee86a22a446e27eb37f06caa63479ca
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2] wifi: ath12k: fix false positive RCU warnings on PREEMPT_RT
From: Jeff Johnson @ 2026-04-22 13:33 UTC (permalink / raw)
To: Yu-Hsiang Tseng, Jeff Johnson, ath12k
Cc: Baochen Qiang, Rameshkumar Sundaram, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, linux-wireless, linux-kernel,
linux-rt-devel
In-Reply-To: <a396cf77-81ff-45a7-ae62-fb4e22c18497@oss.qualcomm.com>
On 4/21/2026 2:27 PM, Jeff Johnson wrote:
> On 4/21/2026 10:25 AM, Yu-Hsiang Tseng wrote:
>> Two functions in ath12k assert that the caller holds an RCU read lock:
>> ath12k_mac_get_arvif() and ath12k_p2p_noa_update_vdev_iter(). Both use:
>>
>> WARN_ON(!rcu_read_lock_any_held());
>>
>> On PREEMPT_RT kernels built with CONFIG_PROVE_RCU=n, this produces a
>> false positive splat whenever these functions are invoked from paths
>> that do hold the RCU read lock (e.g. firmware stats processing or
>> mac80211 interface iteration).
>>
>> Root cause:
>>
>> - On !PROVE_RCU, rcu_read_lock_any_held() is a static inline that
>> returns !preemptible() as a proxy for "in an RCU read section".
>>
>> - On PREEMPT_RT, rcu_read_lock() does not disable preemption. A
>> task can therefore be preemptible while legitimately holding an
>> RCU read lock.
>>
>> - Callers such as ath12k_wmi_tlv_rssi_chain_parse() (via guard(rcu)())
>> and ieee80211_iterate_active_interfaces_atomic() do hold the RCU
>> read lock, so these warnings are incorrect.
>>
>> Typical splat seen on a WCN7850 station with periodic fw stats
>> processing:
>>
>> WARNING: drivers/net/wireless/ath/ath12k/mac.c:791 at
>> ath12k_mac_get_arvif+0x9e/0xd0 [ath12k]
>> Tainted: G W O 6.19.13-rt #1 PREEMPT_RT
>> Call Trace:
>> ath12k_wmi_tlv_rssi_chain_parse+0x69/0x170 [ath12k]
>> ath12k_wmi_tlv_iter+0x7f/0x120 [ath12k]
>> ath12k_wmi_tlv_fw_stats_parse+0x342/0x6b0 [ath12k]
>> ath12k_wmi_op_rx+0xe9e/0x3150 [ath12k]
>> ath12k_htc_rx_completion_handler+0x3df/0x5b0 [ath12k]
>> ath12k_ce_per_engine_service+0x325/0x3e0 [ath12k]
>> ath12k_pci_ce_workqueue+0x20/0x40 [ath12k]
>>
>> Replace the WARN_ON() with RCU_LOCKDEP_WARN(), which is gated on
>> debug_lockdep_rcu_enabled() and therefore compiles out entirely
>> when PROVE_RCU is disabled. PROVE_RCU kernels continue to get the
>> full lockdep-based check.
>>
>> Fixes: 3dd2c68f206e ("wifi: ath12k: prepare vif data structure for MLO handling")
>> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
>
> Note that Tested-on: is not a official upstream tag, it is an ath-specific
> tag. Since it is not an official tag, it should be specified separately from
> the official tags:
>
> <commit text>
> <blank line>
> Tested-on: ...
> <blank line>
> <official upstream tags>
> Signed-off-by: ...
>
> Unless there are are other review comments there is no need to send a v3 to
> address this -- I can make this change when I pick up the patch.
Amended patch in my pending branch:
https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git/commit/?h=pending&id=32f70ee38388bb9089b9cffa9791f5ef8d5d32cd
^ permalink raw reply
* Re: [PATCH ath-next v2 0/5] wifi: ath12k: thermal throttling and cooling device support
From: Rameshkumar Sundaram @ 2026-04-22 13:06 UTC (permalink / raw)
To: Maharaja Kennadyrajan, ath12k; +Cc: linux-wireless
In-Reply-To: <20260413153840.1969931-1-maharaja.kennadyrajan@oss.qualcomm.com>
On 4/13/2026 9:08 PM, Maharaja Kennadyrajan wrote:
> Patch 1 handles the firmware stats event so we can track the current
> temperature and throttle level per pdev without spamming logs.
>
> Patch 2 enables thermal throttling at bring-up and programs default level
> tables to firmware via WMI_THERM_THROT_SET_CONF_CMDID; the driver picks
> IPA/XFEM defaults based on the firmware WMI service bitmap, supports 4 or 5
> levels as advertised, and only fills optional fields (pout reduction,
> tx chain mask) when the corresponding WMI service bits are present.
>
> Patch 3 refactors per-radio thermal hwmon cleanup to reduce code duplication and
> ensure consistent cleanup across thermal register and unregister paths.
>
> Patch 4 reorders the group teardown logic symmetric for safe thermal sysfs cleanup.
>
> Patch 5 exposes a thermal cooling device per radio so the kernel thermal
> framework or userspace can set the TX duty-cycle off percentage; writes
> are validated against the throttling state range and host state is kept in
> sync with successful firmware updates.
>
> Examples:
> echo 40 > /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device/cur_stat
> cat /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device/cur_state
> cat /sys/devices/pci0000:00/0000:00:1d.1/0000:58:00.0/ieee80211/phyX/cooling_device/max_state
>
> v2: Addressed Jeff's comment by rebased on latest TOT with wmi tb - alloc and free
> interface change.
>
> Maharaja Kennadyrajan (5):
> wifi: ath12k: handle thermal throttle stats WMI event
> wifi: ath12k: configure firmware thermal throttling via WMI
> wifi: ath12k: refactor per-radio thermal hwmon setup and cleanup
> wifi: ath12k: reorder group start/stop for safe thermal sysfs cleanup
> wifi: ath12k: add thermal cooling device support
>
> drivers/net/wireless/ath/ath12k/core.c | 50 +++--
> drivers/net/wireless/ath/ath12k/mac.c | 9 +
> drivers/net/wireless/ath/ath12k/thermal.c | 252 ++++++++++++++++++----
> drivers/net/wireless/ath/ath12k/thermal.h | 35 +++
> drivers/net/wireless/ath/ath12k/wmi.c | 108 ++++++++++
> drivers/net/wireless/ath/ath12k/wmi.h | 50 +++++
> 6 files changed, 447 insertions(+), 57 deletions(-)
>
>
> base-commit: 9a4f673eb08d2a7713b258d671b4a45f2a6e68b7
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id
From: Andy Shevchenko @ 2026-04-22 12:44 UTC (permalink / raw)
To: Christian A. Ehrhardt
Cc: Uwe Kleine-König (The Capable Hub), Luiz Augusto von Dentz,
Ulf Hansson, Christian A. Ehrhardt, linux-mmc, Greg Kroah-Hartman,
Wolfram Sang, linux-kernel, Marcel Holtmann, linux-bluetooth,
Matthias Brugger, AngeloGioacchino Del Regno, linux-mediatek,
Ping-Ke Shih, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
Ryder Lee, Shayne Chen, Sean Wang, Brian Norris,
Francesco Dolcini
In-Reply-To: <aeipQfCYKjl006uM@cae.in-ulm.de>
On Wed, Apr 22, 2026 at 12:56:01PM +0200, Christian A. Ehrhardt wrote:
> On Wed, Apr 22, 2026 at 09:52:11AM +0300, Andy Shevchenko wrote:
> > > To be honest, with the involved void* this isn't really type-safe
> > > either, but at least the data keeps being a pointer which is really
> > > helpful on CHERI. FTR: The alternative would be to use uintptr_t instead
> > > of unsigned long, which also has proponents in the CHERI community and
> > > which is used in the current vendor patch stack.
> >
> > FWIW, Linus categorically told that it has to be no uintptr_t in the
> > Linux kernel.
>
> This is probably not the correct context to discuss this but
> I will point out that if/when CHERI support is added to the
> kernel we will need a way to distinguish between
> * A (fat) pointer converted to an integer type (in order to do
> integer arithmetic on the address) that might be converted back
> to a pointer in the future and
> * A plain address "extracted" from a fat pointer.
> Using `uintptr_t` for the former and `unsigned long` for the
> latter seems like a reasonable choice but there are certainly
> other options.
>
> Sorting out the difference between the two is a very large
> part of the diff required to port Linux (or in fact any piece
> of low-level software) to a CHERI system.
Right, whatever CHERI needs is has to be discussed with the project leader(s)
first. But thanks for giving more information on this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id
From: Christian A. Ehrhardt @ 2026-04-22 10:56 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Uwe Kleine-König (The Capable Hub), Luiz Augusto von Dentz,
Ulf Hansson, Christian A. Ehrhardt, linux-mmc, Greg Kroah-Hartman,
Wolfram Sang, linux-kernel, Marcel Holtmann, linux-bluetooth,
Matthias Brugger, AngeloGioacchino Del Regno, linux-mediatek,
Ping-Ke Shih, linux-wireless, Felix Fietkau, Lorenzo Bianconi,
Ryder Lee, Shayne Chen, Sean Wang, Brian Norris,
Francesco Dolcini
In-Reply-To: <aehwG2Egt93-sPVB@ashevche-desk.local>
Hi,
On Wed, Apr 22, 2026 at 09:52:11AM +0300, Andy Shevchenko wrote:
> > To be honest, with the involved void* this isn't really type-safe
> > either, but at least the data keeps being a pointer which is really
> > helpful on CHERI. FTR: The alternative would be to use uintptr_t instead
> > of unsigned long, which also has proponents in the CHERI community and
> > which is used in the current vendor patch stack.
>
> FWIW, Linus categorically told that it has to be no uintptr_t in the
> Linux kernel.
This is probably not the correct context to discuss this but
I will point out that if/when CHERI support is added to the
kernel we will need a way to distinguish between
* A (fat) pointer converted to an integer type (in order to do
integer arithmetic on the address) that might be converted back
to a pointer in the future and
* A plain address "extracted" from a fat pointer.
Using `uintptr_t` for the former and `unsigned long` for the
latter seems like a reasonable choice but there are certainly
other options.
Sorting out the difference between the two is a very large
part of the diff required to port Linux (or in fact any piece
of low-level software) to a CHERI system.
Best regards,
Christian
^ permalink raw reply
* Re: [PATCH] dt-bindings: Fix phandle-array constraints, again
From: Krzysztof Kozlowski @ 2026-04-22 10:22 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Maarten Lankhorst, Maxime Ripard, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Stephan Gerhold, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Johannes Berg, Jeff Johnson, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Andersson,
Mathieu Poirier, Sylwester Nawrocki, Mark Brown, Maxime Coquelin,
Greg Kroah-Hartman, Yang Xiwen, Alex Elder, Chaitanya Chundru,
Sibi Sankar, Rao Mandadapu, Patrice Chotard, Xu Yang, Peng Fan,
Thomas Zimmermann, devicetree, linux-kernel, linux-mmc,
linux-arm-msm, netdev, linux-wireless, ath10k, ath11k, linux-pci,
linux-remoteproc, linux-sound, linux-spi, linux-usb
In-Reply-To: <20260421195836.1547469-1-robh@kernel.org>
On Tue, Apr 21, 2026 at 02:55:25PM -0500, Rob Herring (Arm) wrote:
> diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> index b30544410d09..e47e1e09300a 100644
> --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> @@ -42,7 +42,13 @@ properties:
> description: State bits used by the AP to signal the modem.
> items:
> - description: Power control
> + items:
> + - description: Phandle to ???
> + - description: ???
> - description: Power control acknowledgment
> + items:
> + - description: Phandle to ???
> + - description: ???
>
Here and in all cases except qcom,msm8916-mss-pil:
- description: Phandle to the Shared Memory Point 2 Point device
handling the communication with a remote processor
- description: Single bit index to toggle in the value sent to
the remote processor
maximum: 32
...
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> index c179b560572b..3c614cb7ce88 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> @@ -104,6 +104,9 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop modem
> + items:
> + - description: Phandle to ???
> + - description: ???
- description: Phandle to the Shared Memory Point 2 Point or Shared
Memory Manager device handling the communication with a remote
processor
- description: Single bit index to toggle in the value sent to
the remote processor
maximum: 32
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] NFC: trf7970a: Ignore antenna noise when checking for RF field
From: Paul Geurts @ 2026-04-22 10:09 UTC (permalink / raw)
To: mgreer, sameo, linux-wireless, netdev, linux-kernel
Cc: martijn.de.gouw, Paul Geurts
The main channel Received Signal Strength Indicator (RSSI) measurement
is used to determine whether an RF field is present or not. RSSI != 0
is interpreted as an RF Field is present. This does not take RF noise
and measurement inaccuracy into account, and results in false positives
in the field.
Define a noise level and make sure the RF field is only interpreted as
present when the RSSI is above the noise level.
Fixes: 851ee3cbf850 ("NFC: trf7970a: Don't turn on RF if there is already an RF field")
Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
---
drivers/nfc/trf7970a.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index d17c701c7888..08c27bb438b5 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -317,6 +317,7 @@
#define TRF7970A_RSSI_OSC_STATUS_RSSI_MASK (BIT(2) | BIT(1) | BIT(0))
#define TRF7970A_RSSI_OSC_STATUS_RSSI_X_MASK (BIT(5) | BIT(4) | BIT(3))
#define TRF7970A_RSSI_OSC_STATUS_RSSI_OSC_OK BIT(6)
+#define TRF7970A_RSSI_OSC_STATUS_RSSI_NOISE_LEVEL 1
#define TRF7970A_SPECIAL_FCN_REG1_COL_7_6 BIT(0)
#define TRF7970A_SPECIAL_FCN_REG1_14_ANTICOLL BIT(1)
@@ -1300,7 +1301,7 @@ static int trf7970a_is_rf_field(struct trf7970a *trf, bool *is_rf_field)
if (ret)
return ret;
- if (rssi & TRF7970A_RSSI_OSC_STATUS_RSSI_MASK)
+ if ((rssi & TRF7970A_RSSI_OSC_STATUS_RSSI_MASK) > TRF7970A_RSSI_OSC_STATUS_RSSI_NOISE_LEVEL)
*is_rf_field = true;
else
*is_rf_field = false;
--
2.39.2
^ permalink raw reply related
* Re: [PATCH ath-current] wifi: ath12k: prepare REO update element only for primary link
From: Thorsten Leemhuis @ 2026-04-22 9:30 UTC (permalink / raw)
To: Baochen Qiang, Jeff Johnson
Cc: linux-wireless, ath12k, linux-kernel,
Linux kernel regressions list
In-Reply-To: <20260210-ath12k-rxtid-double-free-v1-1-8b523fb2886d@oss.qualcomm.com>
Lo! Top-posting on purpose to make this easy to process.
Jeff, what happened to below patch? It was supposed to fix the
regression linked below, but unless I'm missing something (which might
very well be the case!) it seems it never got any further than this thread.
Ciao, Thorsten
P.S:: Adding a stable tag might be good to ensure this fix is backported.
On 2/10/26 04:07, Baochen Qiang wrote:
> 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,
^ permalink raw reply
* Re: [PATCH] dt-bindings: Fix phandle-array constraints, again
From: Krzysztof Kozlowski @ 2026-04-22 9:19 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Maarten Lankhorst, Maxime Ripard, Krzysztof Kozlowski,
Conor Dooley, Ulf Hansson, Stephan Gerhold, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Johannes Berg, Jeff Johnson, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Andersson,
Mathieu Poirier, Sylwester Nawrocki, Mark Brown, Maxime Coquelin,
Greg Kroah-Hartman, Yang Xiwen, Alex Elder, Chaitanya Chundru,
Sibi Sankar, Rao Mandadapu, Patrice Chotard, Xu Yang, Peng Fan,
Thomas Zimmermann, devicetree, linux-kernel, linux-mmc,
linux-arm-msm, netdev, linux-wireless, ath10k, ath11k, linux-pci,
linux-remoteproc, linux-sound, linux-spi, linux-usb
In-Reply-To: <20260421195836.1547469-1-robh@kernel.org>
On Tue, Apr 21, 2026 at 02:55:25PM -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.
>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> Can someone from QCom provide some descriptions for 'qcom,smem-states'
> properties.
Working on it...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] wifi: nl80211: require admin perm on SET_PMK / DEL_PMK
From: Arend van Spriel @ 2026-04-22 8:42 UTC (permalink / raw)
To: Johannes Berg, Michael Bommarito, linux-wireless
Cc: Avraham Stern, linux-kernel
In-Reply-To: <e4b3f365a32b633babcd4cefde3fc32460e07e0d.camel@sipsolutions.net>
On 22/04/2026 08:23, Johannes Berg wrote:
> On Tue, 2026-04-21 at 18:45 -0400, Michael Bommarito wrote:
>>
>> Both ops were introduced without a .flags gate, so the generic
>> netlink layer dispatches them to an unprivileged caller instead
>> of rejecting with -EPERM at the permission check. Every other
>> connection-state op in the adjacent block (CONNECT, ASSOCIATE,
>> AUTHENTICATE, SET_KEY, ...) carries GENL_UNS_ADMIN_PERM; SET_PMK
>> / DEL_PMK were introduced without the flag in 2017 and left
>> unchanged by later refactors. Johannes checked the original
>> Intel submission history and confirmed there is no admin check
>> in any prior revision either, so this seems likely to be a
>> simple oversight rather than an intentional carve-out.
>
> FWIW, this submission did originally come from Avi, but we no longer
> have a driver using it (it was never upstream anyway), so that now the
> only affected driver is brcmfmac, AFAICT (other non-upstream drivers I
> wouldn't know, of course.)
>
> Arend, it does seem like the right thing to do here, but I wanted to
> confirm with you and thus asked Michael to CC you, what do you think?
I agree. I saw the patch earlier this morning and acked the patch just now.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id
From: Uwe Kleine-König (The Capable Hub) @ 2026-04-22 8:39 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Luiz Augusto von Dentz, Ulf Hansson, Christian A. Ehrhardt,
linux-mmc, Greg Kroah-Hartman, Wolfram Sang, linux-kernel,
Marcel Holtmann, linux-bluetooth, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mediatek, Ping-Ke Shih,
linux-wireless, Felix Fietkau, Lorenzo Bianconi, Ryder Lee,
Shayne Chen, Sean Wang, Brian Norris, Francesco Dolcini
In-Reply-To: <aehwG2Egt93-sPVB@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
On Wed, Apr 22, 2026 at 09:52:11AM +0300, Andy Shevchenko wrote:
> On Tue, Apr 21, 2026 at 10:12:41AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > On Mon, Apr 20, 2026 at 04:46:56PM -0400, Luiz Augusto von Dentz wrote:
> > > On Mon, Apr 20, 2026 at 4:31 PM Uwe Kleine-König (The Capable Hub)
> > > <u.kleine-koenig@baylibre.com> wrote:
> > > > On Fri, Apr 17, 2026 at 03:10:47PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > > > On all current Linux architectures sizeof(long) == sizeof(void *) and
> > > > > this is used a lot through the kernel. For example it enables the usual
> > > > > practice to store pointers in sdio_driver_id's .driver_data member.
> > > > >
> > > > > This works fine, but involves casting and thus isn't type-safe.
> >
> > To be honest, with the involved void* this isn't really type-safe
> > either, but at least the data keeps being a pointer which is really
> > helpful on CHERI. FTR: The alternative would be to use uintptr_t instead
> > of unsigned long, which also has proponents in the CHERI community and
> > which is used in the current vendor patch stack.
>
> FWIW, Linus categorically told that it has to be no uintptr_t in the Linux kernel.
Then I'm lucky that this patch set doesn't introduce uintptr_t and so we
can delay the discussion with Linus about that. (And we will have to
hold that discussion at some point, because on CHERI we have
sizeof(unsigned long) = 8 < sizeof(void *) = 16. I didn't check, but I
think also unsigned long long cannot hold a void*.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] wifi: nl80211: require admin perm on SET_PMK / DEL_PMK
From: Arend van Spriel @ 2026-04-22 8:32 UTC (permalink / raw)
To: Michael Bommarito, linux-wireless
Cc: Johannes Berg, Avraham Stern, linux-kernel
In-Reply-To: <20260421224552.4044147-1-michael.bommarito@gmail.com>
On 22/04/2026 00:45, Michael Bommarito wrote:
> NL80211_CMD_SET_PMK and NL80211_CMD_DEL_PMK manage the offloaded
> 4-way-handshake PMK state used by drivers advertising
> NL80211_EXT_FEATURE_4WAY_HANDSHAKE_STA_1X. The only in-tree
> driver that wires up both ->set_pmk / ->del_pmk and advertises
> the feature today is brcmfmac, so the practical reach of this
> patch is narrow.
>
> Both ops were introduced without a .flags gate, so the generic
> netlink layer dispatches them to an unprivileged caller instead
> of rejecting with -EPERM at the permission check. Every other
> connection-state op in the adjacent block (CONNECT, ASSOCIATE,
> AUTHENTICATE, SET_KEY, ...) carries GENL_UNS_ADMIN_PERM; SET_PMK
> / DEL_PMK were introduced without the flag in 2017 and left
> unchanged by later refactors. Johannes checked the original
> Intel submission history and confirmed there is no admin check
> in any prior revision either, so this seems likely to be a
> simple oversight rather than an intentional carve-out.
>
> Require GENL_UNS_ADMIN_PERM so the genl layer performs the same
> capable(CAP_NET_ADMIN) check as its siblings. wpa_supplicant
> already needs CAP_NET_ADMIN for every other nl80211 op it issues,
> so supplicant operation is unaffected. The worst case the missing
> gate enables today is an unprivileged local process on a
> multi-user system invalidating the offloaded PMK state of another
> user's 4-way-handshake session, forcing a full EAP re-auth on the
> next reconnect.
>
> Verified in UML: an unprivileged probe (uid=1000) sees
> SET_MULTICAST_TO_UNICAST (sibling op with GENL_UNS_ADMIN_PERM)
> return -EPERM on both pre- and post-fix kernels, while SET_PMK /
> DEL_PMK return -ENODEV from nl80211_pre_doit()'s wdev lookup pre-
> fix (proving dispatch crossed the genl permission check) and
> -EPERM post-fix (rejected at the genl layer as intended).
>
> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
> Fixes: 3a00df5707b6 ("cfg80211: support 4-way handshake offloading for 802.1X")
Good catch. Seems like good thing to do.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom>
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Assisted-by: Claude:claude-opus-4-7
> ---
> net/wireless/nl80211.c | 2 ++
> 1 file changed, 2 insertions(+)
^ permalink raw reply
* Re: [PATCH] wifi: mac80211: check ieee80211_rx_data_set_link return in pubsta MLO path
From: Benjamin Berg @ 2026-04-22 8:17 UTC (permalink / raw)
To: Johannes Berg, Michael Bommarito, linux-wireless
Cc: Felix Fietkau, netdev, linux-kernel, Ramasamy Kaliappan
In-Reply-To: <434407f50d6b7ee85ad14dd6db757f7d9f695a96.camel@sipsolutions.net>
On Wed, 2026-04-22 at 08:27 +0200, Johannes Berg wrote:
> On Tue, 2026-04-21 at 20:06 -0400, Michael Bommarito wrote:
>
> > Benjamin Berg's 2026-02 RFC v2 "wifi: mac80211: refactor RX
> > link_id and station handling"
> > (20260223133818.9f5550ab445f.I...@changeid) touches the same
> > code and may supersede or subsume this patch; happy to fold /
> > rebase / drop.
>
> Yeah, Benjamin, what's up with that :)
Hmm, good question. I was hoping for a userspace hostap implementation
to start using the new NO_STA flag as that part is otherwise untested.
Qualcomm was going to work on that, but I have not yet heard about it
again.
That said, it should be fine to merge patches 1-4 at least. So I am
happy to submit them separately.
Benjamin
>
> OTOH we perhaps wants this patch in wireless, and then yours in
> wireless-next.
>
> johannes
^ permalink raw reply
* Re: [PATCHv2 ath-next] wifi: ath12k: use kzalloc_flex
From: Rameshkumar Sundaram @ 2026-04-22 7:33 UTC (permalink / raw)
To: Rosen Penev, linux-wireless
Cc: Jeff Johnson, Kees Cook, Gustavo A. R. Silva,
open list:QUALCOMM ATH12K WIRELESS DRIVER, open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260421213544.6238-1-rosenp@gmail.com>
On 4/22/2026 3:05 AM, Rosen Penev wrote:
> Convert kzalloc_obj + kcalloc to kzalloc_flex to save an allocation.
>
> Add __counted_by to get extra runtime analysis. Move counting variable
> assignment immediately after allocation before any potential accesses.
> kzalloc_flex does this anyway for GCC >= 15.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
^ 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