* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Jeff Johnson @ 2026-01-16 15:18 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, Vinod Koul, Balakrishna Godavarthi,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Bartosz Golaszewski
In-Reply-To: <15470b51-d398-449d-9017-304df5ad7cef@kernel.org>
On 1/15/2026 11:48 PM, Krzysztof Kozlowski wrote:
> On 15/01/2026 23:30, Jeff Johnson wrote:
>> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
>>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
>>> voltages over internal rails. Implement support for using powersequencer
>>> for this family of ATH10k devices in addition to using regulators.
>>>
>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
>>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
>>
>> My automation flagged:
>> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright
>> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright
>> * 2 copyright issues
>>
>> I'll add these manually in my 'pending' branch
>>
>
> And why is this a problem? You are not here to impose Qualcomm rules, bu
> care about Linux kernel. You cannot add copyrights based on what exactly?
I am a maintainer that is paid by Qualcomm to perform that role, and hence I
have a duty to enforce the legal guidance from Qualcomm when it comes to
contributions from other Qualcomm employees.
/jeff
^ permalink raw reply
* [PATCH] wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()
From: Zilin Guan @ 2026-01-16 14:49 UTC (permalink / raw)
To: nbd
Cc: lorenzo, ryder.lee, shayne.chen, sean.wang, matthias.bgg,
angelogioacchino.delregno, linux-wireless, linux-kernel,
linux-arm-kernel, linux-mediatek, jianhao.xu, Zilin Guan
mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to
be freed eventually by mt76_mcu_skb_send_msg(). However, currently if
an intermediate function fails before sending, the allocated skb is
leaked.
Specifically, mt76_connac_mcu_sta_wed_update() and
mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory
leak in the error path.
Fix this by explicitly freeing the skb in these error paths.
Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on
mt7996_mcu_sta_key_tlv error") made a similar change.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Fixes: d1369e515efe ("wifi: mt76: connac: introduce mt76_connac_mcu_sta_wed_update utility routine")
Fixes: 6683d988089c ("mt76: connac: move mt76_connac_mcu_add_key in connac module")
Fixes: 4f831d18d12d ("wifi: mt76: mt7915: enable WED RX support")
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
.../net/wireless/mediatek/mt76/mt76_connac_mcu.c | 16 ++++++++++++----
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 4 +++-
drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 +++-
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
index 0457712286d5..3f583e2a1dc1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c
@@ -1295,8 +1295,10 @@ int mt76_connac_mcu_sta_ba(struct mt76_dev *dev, struct mt76_vif_link *mvif,
wtbl_hdr);
ret = mt76_connac_mcu_sta_wed_update(dev, skb);
- if (ret)
+ if (ret) {
+ dev_kfree_skb(skb);
return ret;
+ }
ret = mt76_mcu_skb_send_msg(dev, skb, cmd, true);
if (ret)
@@ -1309,8 +1311,10 @@ int mt76_connac_mcu_sta_ba(struct mt76_dev *dev, struct mt76_vif_link *mvif,
mt76_connac_mcu_sta_ba_tlv(skb, params, enable, tx);
ret = mt76_connac_mcu_sta_wed_update(dev, skb);
- if (ret)
+ if (ret) {
+ dev_kfree_skb(skb);
return ret;
+ }
return mt76_mcu_skb_send_msg(dev, skb, cmd, true);
}
@@ -2764,12 +2768,16 @@ int mt76_connac_mcu_add_key(struct mt76_dev *dev, struct ieee80211_vif *vif,
return PTR_ERR(skb);
ret = mt76_connac_mcu_sta_key_tlv(sta_key_conf, skb, key, cmd);
- if (ret)
+ if (ret) {
+ dev_kfree_skb(skb);
return ret;
+ }
ret = mt76_connac_mcu_sta_wed_update(dev, skb);
- if (ret)
+ if (ret) {
+ dev_kfree_skb(skb);
return ret;
+ }
return mt76_mcu_skb_send_msg(dev, skb, mcu_cmd, true);
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
index 00bff4d3aab8..04ec821225eb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
@@ -1765,8 +1765,10 @@ int mt7915_mcu_add_sta(struct mt7915_dev *dev, struct ieee80211_vif *vif,
}
out:
ret = mt76_connac_mcu_sta_wed_update(&dev->mt76, skb);
- if (ret)
+ if (ret) {
+ dev_kfree_skb(skb);
return ret;
+ }
return mt76_mcu_skb_send_msg(&dev->mt76, skb,
MCU_EXT_CMD(STA_REC_UPDATE), true);
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
index cf0fdea45cf7..3bddd357cd0d 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c
@@ -1288,8 +1288,10 @@ int mt7925_mcu_add_key(struct mt76_dev *dev, struct ieee80211_vif *vif,
return PTR_ERR(skb);
ret = mt7925_mcu_sta_key_tlv(wcid, sta_key_conf, skb, key, cmd, msta);
- if (ret)
+ if (ret) {
+ dev_kfree_skb(skb);
return ret;
+ }
return mt76_mcu_skb_send_msg(dev, skb, mcu_cmd, true);
}
--
2.34.1
^ permalink raw reply related
* Re: wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Johannes Berg @ 2026-01-16 13:48 UTC (permalink / raw)
To: Markus Elfring, Zong-Zhe Yang, Zilin Guan, Ping-Ke Shih,
linux-wireless, kernel-janitors
Cc: LKML, Jianhao Xu
In-Reply-To: <0ad16f51-8caf-469b-882d-4928560c0b64@web.de>
For the record, everyone, please just ignore Markus. I've told him
numerous times to just leave us alone.
johannes
^ permalink raw reply
* [PATCH v2] wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Zilin Guan @ 2026-01-16 13:08 UTC (permalink / raw)
To: pkshih; +Cc: kevin_yang, linux-wireless, linux-kernel, jianhao.xu, Zilin Guan
In __print_txpwr_map(), memory is allocated to bufp via vzalloc().
If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately
without freeing bufp, leading to a memory leak.
Since the validation of max_valid_addr does not depend on the allocated
memory, fix this by moving the vzalloc() call after the check.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips")
Suggested-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
Changes in v2:
- Move memory allocation after validation check to avoid leak.
drivers/net/wireless/realtek/rtw89/debug.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw89/debug.c b/drivers/net/wireless/realtek/rtw89/debug.c
index 1264c2f82600..987eef8170f2 100644
--- a/drivers/net/wireless/realtek/rtw89/debug.c
+++ b/drivers/net/wireless/realtek/rtw89/debug.c
@@ -825,10 +825,6 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char *buf, size_t buf
s8 *bufp, tmp;
int ret;
- bufp = vzalloc(map->addr_to - map->addr_from + 4);
- if (!bufp)
- return -ENOMEM;
-
if (path_num == 1)
max_valid_addr = map->addr_to_1ss;
else
@@ -837,6 +833,10 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char *buf, size_t buf
if (max_valid_addr == 0)
return -EOPNOTSUPP;
+ bufp = vzalloc(map->addr_to - map->addr_from + 4);
+ if (!bufp)
+ return -ENOMEM;
+
for (addr = map->addr_from; addr <= max_valid_addr; addr += 4) {
ret = rtw89_mac_txpwr_read32(rtwdev, RTW89_PHY_0, addr, &val);
if (ret)
--
2.34.1
^ permalink raw reply related
* Re: wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Markus Elfring @ 2026-01-16 12:38 UTC (permalink / raw)
To: Zong-Zhe Yang, Zilin Guan, Ping-Ke Shih, linux-wireless,
kernel-janitors
Cc: LKML, Jianhao Xu
In-Reply-To: <acc90353107248b98215847e56bb374b@realtek.com>
> But, I don't seem to see DEFINE_FREE(vfree, ...) yet.
…
Would you dare to support the addition of such a macro call anyhow?
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/cleanup.h#L157-L161
Regards,
Markus
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Zilin Guan @ 2026-01-16 12:11 UTC (permalink / raw)
To: kevin_yang; +Cc: jianhao.xu, linux-kernel, linux-wireless, pkshih, zilin
In-Reply-To: <2df4d692f5804c8ca87d3cd26b37081e@realtek.com>
On Fri, Jan 16, 2026 at 08:23:57AM +0000, Zong-Zhe Yang wrote:
> > @@ -834,8 +834,10 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char
> > *buf, size_t buf
> > else
> > max_valid_addr = map->addr_to;
> >
> > - if (max_valid_addr == 0)
> > + if (max_valid_addr == 0) {
> > + vfree(bufp);
> > return -EOPNOTSUPP;
> > + }
>
> Thank you for catching this.
> Since the decision for max_valid_addr doesn't depend on bufp,
> how about moving vzalloc down here ?
>
> >
> > for (addr = map->addr_from; addr <= max_valid_addr; addr += 4) {
> > ret = rtw89_mac_txpwr_read32(rtwdev, RTW89_PHY_0, addr, &val);
> > --
> > 2.34.1
> >
Thanks for your suggestion. I agree that moving vzalloc() after the check
is a cleaner solution. I will send a v2 patch to address this.
Best Regards,
Zilin Guan
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Zong-Zhe Yang @ 2026-01-16 11:41 UTC (permalink / raw)
To: Markus Elfring, Zilin Guan, linux-wireless@vger.kernel.org,
Ping-Ke Shih
Cc: LKML, kernel-janitors@vger.kernel.org, Jianhao Xu
In-Reply-To: <1d32418f-c315-4ce4-9b4c-6781bda72cfe@web.de>
Markus Elfring <Markus.Elfring@web.de> wrote:
>
> …
> > Fix this by freeing the temporary buffer bufp in the error path.
> …
>
> How do you think about to use an attribute like “__free(vfree)”?
> https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/net/wireless/realtek/rtw89/debug.c#
> L815-L858
>
Using __free(XXX) is fine to me.
But, I don't seem to see DEFINE_FREE(vfree, ...) yet.
So perhaps, need to use __free(kvfree).
^ permalink raw reply
* Re: [PATCH] wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Markus Elfring @ 2026-01-16 11:04 UTC (permalink / raw)
To: Zilin Guan, linux-wireless, Ping-Ke Shih
Cc: LKML, kernel-janitors, Jianhao Xu, Zong-Zhe Yang
In-Reply-To: <20260116074836.1199951-1-zilin@seu.edu.cn>
…
> Fix this by freeing the temporary buffer bufp in the error path.
…
How do you think about to use an attribute like “__free(vfree)”?
https://elixir.bootlin.com/linux/v6.19-rc5/source/drivers/net/wireless/realtek/rtw89/debug.c#L815-L858
Regards,
Markus
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Zong-Zhe Yang @ 2026-01-16 8:23 UTC (permalink / raw)
To: Zilin Guan, Ping-Ke Shih
Cc: jianhao.xu@seu.edu.cn, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260116074836.1199951-1-zilin@seu.edu.cn>
Zilin Guan <zilin@seu.edu.cn> wrote:
>
> In __print_txpwr_map(), memory is allocated to bufp via vzalloc().
> If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately
> without freeing bufp, leading to a memory leak.
>
> Fix this by freeing the temporary buffer bufp in the error path.
>
> Compile tested only. Issue found using a prototype static analysis tool
> and code review.
>
> Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips")
> Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
> ---
> drivers/net/wireless/realtek/rtw89/debug.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/debug.c
> b/drivers/net/wireless/realtek/rtw89/debug.c
> index 1264c2f82600..c7bd1d0212b6 100644
> --- a/drivers/net/wireless/realtek/rtw89/debug.c
> +++ b/drivers/net/wireless/realtek/rtw89/debug.c
> @@ -834,8 +834,10 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char
> *buf, size_t buf
> else
> max_valid_addr = map->addr_to;
>
> - if (max_valid_addr == 0)
> + if (max_valid_addr == 0) {
> + vfree(bufp);
> return -EOPNOTSUPP;
> + }
Thank you for catching this.
Since the decision for max_valid_addr doesn't depend on bufp,
how about moving vzalloc down here ?
>
> for (addr = map->addr_from; addr <= max_valid_addr; addr += 4) {
> ret = rtw89_mac_txpwr_read32(rtwdev, RTW89_PHY_0, addr, &val);
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH wireless-next] wifi: mac80211: mark iface work SKBs as consumed
From: Johannes Berg @ 2026-01-16 8:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Using kfree_skb() here is misleading when looking at
traces, since these frames have been handled. Use
consume_skb() instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/iface.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 7b0aa24c1f97..3ce94b95decd 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -8,7 +8,7 @@
* Copyright 2008, Johannes Berg <johannes@sipsolutions.net>
* Copyright 2013-2014 Intel Mobile Communications GmbH
* Copyright (c) 2016 Intel Deutschland GmbH
- * Copyright (C) 2018-2025 Intel Corporation
+ * Copyright (C) 2018-2026 Intel Corporation
*/
#include <linux/slab.h>
#include <linux/kernel.h>
@@ -1789,7 +1789,7 @@ static void ieee80211_iface_work(struct wiphy *wiphy, struct wiphy_work *work)
else
ieee80211_iface_process_skb(local, sdata, skb);
- kfree_skb(skb);
+ consume_skb(skb);
kcov_remote_stop();
}
@@ -1798,7 +1798,7 @@ static void ieee80211_iface_work(struct wiphy *wiphy, struct wiphy_work *work)
kcov_remote_start_common(skb_get_kcov_handle(skb));
ieee80211_iface_process_status(sdata, skb);
- kfree_skb(skb);
+ consume_skb(skb);
kcov_remote_stop();
}
--
2.52.0
^ permalink raw reply related
* [PATCH wireless-next] wifi: mac80211: remove RX_DROP
From: Johannes Berg @ 2026-01-16 8:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Since it's hard to figure out what RX_DROP means when looking
at traces that drop packets in mac80211, add more specific drop
reasons and remove RX_DROP entirely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/drop.h | 46 ++++++++++++++++++++-
net/mac80211/rx.c | 98 +++++++++++++++++++++++----------------------
2 files changed, 94 insertions(+), 50 deletions(-)
diff --git a/net/mac80211/drop.h b/net/mac80211/drop.h
index eb9ab310f91c..f06a8aa905c5 100644
--- a/net/mac80211/drop.h
+++ b/net/mac80211/drop.h
@@ -2,7 +2,7 @@
/*
* mac80211 drop reason list
*
- * Copyright (C) 2023-2024 Intel Corporation
+ * Copyright (C) 2023-2024, 2026 Intel Corporation
*/
#ifndef MAC80211_DROP_H
@@ -65,6 +65,49 @@ typedef unsigned int __bitwise ieee80211_rx_result;
/* 0x30 */ \
R(RX_DROP_U_BAD_MGMT_KEYIDX) \
R(RX_DROP_U_UNKNOWN_ACTION_REJECTED) \
+ R(RX_DROP_U_MESH_DS_BITS) \
+ R(RX_DROP_U_MESH_A3_MISMATCH) \
+ R(RX_DROP_U_MESH_NO_A4) \
+ R(RX_DROP_U_MESH_A4_MISMATCH) \
+ R(RX_DROP_U_MESH_UNEXP_DATA) \
+ R(RX_DROP_U_MESH_WRONG_ACTION) \
+ R(RX_DROP_U_MESH_UNEXP_MGMT) \
+ R(RX_DROP_U_SPURIOUS_NOTIF) \
+ R(RX_DROP_U_RUNT_DATA) \
+ R(RX_DROP_U_KEY_TAINTED) \
+ R(RX_DROP_U_UNPROTECTED) \
+ R(RX_DROP_U_MCAST_FRAGMENT) \
+ R(RX_DROP_U_DEFRAG_MISMATCH) \
+ R(RX_DROP_U_RUNT_MESH_DATA) \
+ /* 0x40 */ \
+ R(RX_DROP_U_MESH_NO_TTL) \
+ R(RX_DROP_U_MESH_RMC) \
+ R(RX_DROP_U_MESH_BAD_AE) \
+ R(RX_DROP_U_MESH_TTL_EXPIRED) \
+ R(RX_DROP_U_MESH_NOT_FORWARDING) \
+ R(RX_DROP_U_AMSDU_WITHOUT_DATA) \
+ R(RX_DROP_U_NULL_DATA) \
+ R(RX_DROP_U_UNEXPECTED_4ADDR) \
+ R(RX_DROP_U_PORT_CONTROL) \
+ R(RX_DROP_U_UNKNOWN_STA) \
+ R(RX_DROP_U_RUNT_BAR) \
+ R(RX_DROP_U_BAR_OUTSIDE_SESSION) \
+ R(RX_DROP_U_CTRL_FRAME) \
+ R(RX_DROP_U_RUNT_MGMT) \
+ R(RX_DROP_U_EXPECTED_MGMT) \
+ R(RX_DROP_U_NONBCAST_BEACON) \
+ /* 0x50 */ \
+ R(RX_DROP_U_MALFORMED_ACTION) \
+ R(RX_DROP_U_UNKNOWN_MCAST_ACTION) \
+ R(RX_DROP_U_UNEXPECTED_EXT_FRAME) \
+ R(RX_DROP_U_UNHANDLED_MGMT) \
+ R(RX_DROP_U_MCAST_DEAUTH) \
+ R(RX_DROP_U_UNHANDLED_DEAUTH) \
+ R(RX_DROP_U_MCAST_DISASSOC) \
+ R(RX_DROP_U_UNHANDLED_DISASSOC) \
+ R(RX_DROP_U_UNHANDLED_PREQ) \
+ R(RX_DROP_U_UNHANDLED_MGMT_STYPE) \
+ R(RX_DROP_U_NO_LINK) \
/* this line for the trailing \ - add before this */
/* having two enums allows for checking ieee80211_rx_result use with sparse */
@@ -85,7 +128,6 @@ enum ___mac80211_drop_reason {
enum mac80211_drop_reason {
RX_CONTINUE = (__force ieee80211_rx_result)___RX_CONTINUE,
RX_QUEUED = (__force ieee80211_rx_result)___RX_QUEUED,
- RX_DROP = (__force ieee80211_rx_result)___RX_DROP_UNUSABLE,
#define DEF(x) x = (__force ieee80211_rx_result)___ ## x,
MAC80211_DROP_REASONS_UNUSABLE(DEF)
#undef DEF
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9a2b0ef2f21a..ac437256f5d5 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -6,7 +6,7 @@
* Copyright 2007-2010 Johannes Berg <johannes@sipsolutions.net>
* Copyright 2013-2014 Intel Mobile Communications GmbH
* Copyright(c) 2015 - 2017 Intel Deutschland GmbH
- * Copyright (C) 2018-2025 Intel Corporation
+ * Copyright (C) 2018-2026 Intel Corporation
*/
#include <linux/jiffies.h>
@@ -1137,14 +1137,14 @@ static ieee80211_rx_result ieee80211_rx_mesh_check(struct ieee80211_rx_data *rx)
if (is_multicast_ether_addr(hdr->addr1)) {
if (ieee80211_has_tods(hdr->frame_control) ||
!ieee80211_has_fromds(hdr->frame_control))
- return RX_DROP;
+ return RX_DROP_U_MESH_DS_BITS;
if (ether_addr_equal(hdr->addr3, dev_addr))
- return RX_DROP;
+ return RX_DROP_U_MESH_A3_MISMATCH;
} else {
if (!ieee80211_has_a4(hdr->frame_control))
- return RX_DROP;
+ return RX_DROP_U_MESH_NO_A4;
if (ether_addr_equal(hdr->addr4, dev_addr))
- return RX_DROP;
+ return RX_DROP_U_MESH_A4_MISMATCH;
}
}
@@ -1156,20 +1156,20 @@ static ieee80211_rx_result ieee80211_rx_mesh_check(struct ieee80211_rx_data *rx)
struct ieee80211_mgmt *mgmt;
if (!ieee80211_is_mgmt(hdr->frame_control))
- return RX_DROP;
+ return RX_DROP_U_MESH_UNEXP_DATA;
if (ieee80211_is_action(hdr->frame_control)) {
u8 category;
/* make sure category field is present */
if (rx->skb->len < IEEE80211_MIN_ACTION_SIZE)
- return RX_DROP;
+ return RX_DROP_U_RUNT_ACTION;
mgmt = (struct ieee80211_mgmt *)hdr;
category = mgmt->u.action.category;
if (category != WLAN_CATEGORY_MESH_ACTION &&
category != WLAN_CATEGORY_SELF_PROTECTED)
- return RX_DROP;
+ return RX_DROP_U_MESH_WRONG_ACTION;
return RX_CONTINUE;
}
@@ -1179,7 +1179,7 @@ static ieee80211_rx_result ieee80211_rx_mesh_check(struct ieee80211_rx_data *rx)
ieee80211_is_auth(hdr->frame_control))
return RX_CONTINUE;
- return RX_DROP;
+ return RX_DROP_U_MESH_UNEXP_MGMT;
}
return RX_CONTINUE;
@@ -1605,7 +1605,7 @@ ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
hdrlen = ieee80211_hdrlen(hdr->frame_control);
if (rx->skb->len < hdrlen + 8)
- return RX_DROP;
+ return RX_DROP_U_RUNT_DATA;
skb_copy_bits(rx->skb, hdrlen + 6, ðertype, 2);
if (ethertype == rx->sdata->control_port_protocol)
@@ -1615,9 +1615,9 @@ ieee80211_rx_h_check(struct ieee80211_rx_data *rx)
if (rx->sdata->vif.type == NL80211_IFTYPE_AP &&
cfg80211_rx_spurious_frame(rx->sdata->dev, hdr->addr2,
rx->link_id, GFP_ATOMIC))
- return RX_DROP_U_SPURIOUS;
+ return RX_DROP_U_SPURIOUS_NOTIF;
- return RX_DROP;
+ return RX_DROP_U_SPURIOUS;
}
return RX_CONTINUE;
@@ -2106,7 +2106,7 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
if (rx->link_sta) {
if (ieee80211_is_group_privacy_action(skb) &&
test_sta_flag(rx->sta, WLAN_STA_MFP))
- return RX_DROP;
+ return RX_DROP_U_UNPROTECTED;
rx->key = rcu_dereference(rx->link_sta->gtk[mmie_keyidx]);
}
@@ -2191,11 +2191,11 @@ ieee80211_rx_h_decrypt(struct ieee80211_rx_data *rx)
if (rx->key) {
if (unlikely(rx->key->flags & KEY_FLAG_TAINTED))
- return RX_DROP;
+ return RX_DROP_U_KEY_TAINTED;
/* TODO: add threshold stuff again */
} else {
- return RX_DROP;
+ return RX_DROP_U_UNPROTECTED;
}
switch (rx->key->conf.cipher) {
@@ -2371,7 +2371,7 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
goto out;
if (is_multicast_ether_addr(hdr->addr1))
- return RX_DROP;
+ return RX_DROP_U_MCAST_FRAGMENT;
I802_DEBUG_INC(rx->local->rx_handlers_fragments);
@@ -2426,7 +2426,7 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
rx->seqno_idx, hdr);
if (!entry) {
I802_DEBUG_INC(rx->local->rx_handlers_drop_defrag);
- return RX_DROP;
+ return RX_DROP_U_DEFRAG_MISMATCH;
}
/* "The receiver shall discard MSDUs and MMPDUs whose constituent
@@ -2956,25 +2956,25 @@ ieee80211_rx_mesh_data(struct ieee80211_sub_if_data *sdata, struct sta_info *sta
return RX_CONTINUE;
if (!pskb_may_pull(skb, sizeof(*eth) + 6))
- return RX_DROP;
+ return RX_DROP_U_RUNT_MESH_DATA;
mesh_hdr = (struct ieee80211s_hdr *)(skb->data + sizeof(*eth));
mesh_hdrlen = ieee80211_get_mesh_hdrlen(mesh_hdr);
if (!pskb_may_pull(skb, sizeof(*eth) + mesh_hdrlen))
- return RX_DROP;
+ return RX_DROP_U_RUNT_MESH_DATA;
eth = (struct ethhdr *)skb->data;
multicast = is_multicast_ether_addr(eth->h_dest);
mesh_hdr = (struct ieee80211s_hdr *)(eth + 1);
if (!mesh_hdr->ttl)
- return RX_DROP;
+ return RX_DROP_U_MESH_NO_TTL;
/* frame is in RMC, don't forward */
if (is_multicast_ether_addr(eth->h_dest) &&
mesh_rmc_check(sdata, eth->h_source, mesh_hdr))
- return RX_DROP;
+ return RX_DROP_U_MESH_RMC;
/* forward packet */
if (sdata->crypto_tx_tailroom_needed_cnt)
@@ -2991,7 +2991,7 @@ ieee80211_rx_mesh_data(struct ieee80211_sub_if_data *sdata, struct sta_info *sta
/* has_a4 already checked in ieee80211_rx_mesh_check */
proxied_addr = mesh_hdr->eaddr2;
else
- return RX_DROP;
+ return RX_DROP_U_MESH_BAD_AE;
rcu_read_lock();
mppath = mpp_path_lookup(sdata, proxied_addr);
@@ -3023,14 +3023,14 @@ ieee80211_rx_mesh_data(struct ieee80211_sub_if_data *sdata, struct sta_info *sta
goto rx_accept;
IEEE80211_IFSTA_MESH_CTR_INC(ifmsh, dropped_frames_ttl);
- return RX_DROP;
+ return RX_DROP_U_MESH_TTL_EXPIRED;
}
if (!ifmsh->mshcfg.dot11MeshForwarding) {
if (is_multicast_ether_addr(eth->h_dest))
goto rx_accept;
- return RX_DROP;
+ return RX_DROP_U_MESH_NOT_FORWARDING;
}
skb_set_queue_mapping(skb, ieee802_1d_to_ac[skb->priority]);
@@ -3216,7 +3216,7 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
return RX_CONTINUE;
if (unlikely(!ieee80211_is_data_present(fc)))
- return RX_DROP;
+ return RX_DROP_U_AMSDU_WITHOUT_DATA;
if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
switch (rx->sdata->vif.type) {
@@ -3273,7 +3273,7 @@ ieee80211_rx_h_data(struct ieee80211_rx_data *rx)
return RX_CONTINUE;
if (unlikely(!ieee80211_is_data_present(hdr->frame_control)))
- return RX_DROP;
+ return RX_DROP_U_NULL_DATA;
/* Send unexpected-4addr-frame event to hostapd */
if (ieee80211_has_a4(hdr->frame_control) &&
@@ -3283,7 +3283,7 @@ ieee80211_rx_h_data(struct ieee80211_rx_data *rx)
cfg80211_rx_unexpected_4addr_frame(
rx->sdata->dev, rx->sta->sta.addr, rx->link_id,
GFP_ATOMIC);
- return RX_DROP;
+ return RX_DROP_U_UNEXPECTED_4ADDR;
}
res = __ieee80211_data_to_8023(rx, &port_control);
@@ -3295,7 +3295,7 @@ ieee80211_rx_h_data(struct ieee80211_rx_data *rx)
return res;
if (!ieee80211_frame_allowed(rx, fc))
- return RX_DROP;
+ return RX_DROP_U_PORT_CONTROL;
/* directly handle TDLS channel switch requests/responses */
if (unlikely(((struct ethhdr *)rx->skb->data)->h_proto ==
@@ -3360,11 +3360,11 @@ ieee80211_rx_h_ctrl(struct ieee80211_rx_data *rx, struct sk_buff_head *frames)
};
if (!rx->sta)
- return RX_DROP;
+ return RX_DROP_U_UNKNOWN_STA;
if (skb_copy_bits(skb, offsetof(struct ieee80211_bar, control),
&bar_data, sizeof(bar_data)))
- return RX_DROP;
+ return RX_DROP_U_RUNT_BAR;
tid = le16_to_cpu(bar_data.control) >> 12;
@@ -3376,7 +3376,7 @@ ieee80211_rx_h_ctrl(struct ieee80211_rx_data *rx, struct sk_buff_head *frames)
tid_agg_rx = rcu_dereference(rx->sta->ampdu_mlme.tid_rx[tid]);
if (!tid_agg_rx)
- return RX_DROP;
+ return RX_DROP_U_BAR_OUTSIDE_SESSION;
start_seq_num = le16_to_cpu(bar_data.start_seq_num) >> 4;
event.u.ba.tid = tid;
@@ -3400,7 +3400,7 @@ ieee80211_rx_h_ctrl(struct ieee80211_rx_data *rx, struct sk_buff_head *frames)
return RX_QUEUED;
}
- return RX_DROP;
+ return RX_DROP_U_CTRL_FRAME;
}
static void ieee80211_process_sa_query_req(struct ieee80211_sub_if_data *sdata,
@@ -3509,10 +3509,10 @@ ieee80211_rx_h_mgmt_check(struct ieee80211_rx_data *rx)
* and unknown (reserved) frames are useless.
*/
if (rx->skb->len < 24)
- return RX_DROP;
+ return RX_DROP_U_RUNT_MGMT;
if (!ieee80211_is_mgmt(mgmt->frame_control))
- return RX_DROP;
+ return RX_DROP_U_EXPECTED_MGMT;
/* drop too small action frames */
if (ieee80211_is_action(mgmt->frame_control) &&
@@ -3522,7 +3522,7 @@ ieee80211_rx_h_mgmt_check(struct ieee80211_rx_data *rx)
/* Drop non-broadcast Beacon frames */
if (ieee80211_is_beacon(mgmt->frame_control) &&
!is_broadcast_ether_addr(mgmt->da))
- return RX_DROP;
+ return RX_DROP_U_NONBCAST_BEACON;
if (rx->sdata->vif.type == NL80211_IFTYPE_AP &&
ieee80211_is_beacon(mgmt->frame_control) &&
@@ -4054,10 +4054,10 @@ ieee80211_rx_h_action_return(struct ieee80211_rx_data *rx)
if (!(status->rx_flags & IEEE80211_RX_MALFORMED_ACTION_FRM) &&
(sdata->vif.type == NL80211_IFTYPE_AP ||
sdata->vif.type == NL80211_IFTYPE_AP_VLAN))
- return RX_DROP;
+ return RX_DROP_U_MALFORMED_ACTION;
if (is_multicast_ether_addr(mgmt->da))
- return RX_DROP;
+ return RX_DROP_U_UNKNOWN_MCAST_ACTION;
/* do not return rejected action frames */
if (mgmt->u.action.category & 0x80)
@@ -4102,7 +4102,7 @@ ieee80211_rx_h_ext(struct ieee80211_rx_data *rx)
return RX_CONTINUE;
if (sdata->vif.type != NL80211_IFTYPE_STATION)
- return RX_DROP;
+ return RX_DROP_U_UNEXPECTED_EXT_FRAME;
/* for now only beacons are ext, so queue them */
ieee80211_queue_skb_to_iface(sdata, rx->link_id, rx->sta, rx->skb);
@@ -4123,7 +4123,7 @@ ieee80211_rx_h_mgmt(struct ieee80211_rx_data *rx)
sdata->vif.type != NL80211_IFTYPE_ADHOC &&
sdata->vif.type != NL80211_IFTYPE_OCB &&
sdata->vif.type != NL80211_IFTYPE_STATION)
- return RX_DROP;
+ return RX_DROP_U_UNHANDLED_MGMT;
switch (stype) {
case cpu_to_le16(IEEE80211_STYPE_AUTH):
@@ -4134,32 +4134,32 @@ ieee80211_rx_h_mgmt(struct ieee80211_rx_data *rx)
case cpu_to_le16(IEEE80211_STYPE_DEAUTH):
if (is_multicast_ether_addr(mgmt->da) &&
!is_broadcast_ether_addr(mgmt->da))
- return RX_DROP;
+ return RX_DROP_U_MCAST_DEAUTH;
/* process only for station/IBSS */
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_ADHOC)
- return RX_DROP;
+ return RX_DROP_U_UNHANDLED_DEAUTH;
break;
case cpu_to_le16(IEEE80211_STYPE_ASSOC_RESP):
case cpu_to_le16(IEEE80211_STYPE_REASSOC_RESP):
case cpu_to_le16(IEEE80211_STYPE_DISASSOC):
if (is_multicast_ether_addr(mgmt->da) &&
!is_broadcast_ether_addr(mgmt->da))
- return RX_DROP;
+ return RX_DROP_U_MCAST_DISASSOC;
/* process only for station */
if (sdata->vif.type != NL80211_IFTYPE_STATION)
- return RX_DROP;
+ return RX_DROP_U_UNHANDLED_DISASSOC;
break;
case cpu_to_le16(IEEE80211_STYPE_PROBE_REQ):
/* process only for ibss and mesh */
if (sdata->vif.type != NL80211_IFTYPE_ADHOC &&
sdata->vif.type != NL80211_IFTYPE_MESH_POINT)
- return RX_DROP;
+ return RX_DROP_U_UNHANDLED_PREQ;
break;
default:
- return RX_DROP;
+ return RX_DROP_U_UNHANDLED_MGMT_STYPE;
}
ieee80211_queue_skb_to_iface(sdata, rx->link_id, rx->sta, rx->skb);
@@ -4187,7 +4187,7 @@ static void ieee80211_rx_handlers_result(struct ieee80211_rx_data *rx,
static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
struct sk_buff_head *frames)
{
- ieee80211_rx_result res = RX_DROP;
+ ieee80211_rx_result res;
struct sk_buff *skb;
#define CALL_RXH(rxh) \
@@ -4213,8 +4213,10 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
*/
rx->skb = skb;
- if (WARN_ON_ONCE(!rx->link))
+ if (WARN_ON_ONCE(!rx->link)) {
+ res = RX_DROP_U_NO_LINK;
goto rxh_next;
+ }
CALL_RXH(ieee80211_rx_h_check_more_data);
CALL_RXH(ieee80211_rx_h_uapsd_and_pspoll);
@@ -4251,7 +4253,7 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
static void ieee80211_invoke_rx_handlers(struct ieee80211_rx_data *rx)
{
struct sk_buff_head reorder_release;
- ieee80211_rx_result res = RX_DROP;
+ ieee80211_rx_result res;
__skb_queue_head_init(&reorder_release);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH wireless-next v4 0/9] wifi: cfg80211/mac80211: Add Support for EPPKE Authentication
From: Johannes Berg @ 2026-01-16 8:17 UTC (permalink / raw)
To: Kavita Kavita; +Cc: linux-wireless, ainy.kumari, sai.magam, quic_drohan
In-Reply-To: <20260114111900.2196941-1-kavita.kavita@oss.qualcomm.com>
On Wed, 2026-01-14 at 16:48 +0530, Kavita Kavita wrote:
> This patch series introduces support for the Enhanced Privacy
> Protection Key Exchange (EPPKE) authentication protocol, as defined in
> "IEEE P802.11bi/D3.0, 12.16.9". The implementation covers both AP and
> non-AP STA modes, with clear separation in the commit descriptions.
>
> The changes have been validated end-to-end using the hwsim tool.
>
> During development and testing of EPPKE feature, we encountered an
> issue in mac80211 related to incorrect AAD/Nonce computation for
> management frames when MLO address translation is involved.
> Depends-on: [PATCH wireless-next] wifi: mac80211: Fix AAD/Nonce
> computation for management frames with MLO
>
> Without the patch, EPPKE functionality will fail for MLO connection.
Because of that, I've only applied patches 1-8 for now, so the feature
isn't enabled anywhere until we fix that issue.
johannes
^ permalink raw reply
* [PATCH] wifi: rtw89: debug: Fix memory leak in __print_txpwr_map()
From: Zilin Guan @ 2026-01-16 7:48 UTC (permalink / raw)
To: pkshih; +Cc: jianhao.xu, linux-wireless, linux-kernel, Zilin Guan
In __print_txpwr_map(), memory is allocated to bufp via vzalloc().
If max_valid_addr is 0, the function returns -EOPNOTSUPP immediately
without freeing bufp, leading to a memory leak.
Fix this by freeing the temporary buffer bufp in the error path.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Fixes: 036042e15770 ("wifi: rtw89: debug: txpwr table supports Wi-Fi 7 chips")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
---
drivers/net/wireless/realtek/rtw89/debug.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw89/debug.c b/drivers/net/wireless/realtek/rtw89/debug.c
index 1264c2f82600..c7bd1d0212b6 100644
--- a/drivers/net/wireless/realtek/rtw89/debug.c
+++ b/drivers/net/wireless/realtek/rtw89/debug.c
@@ -834,8 +834,10 @@ static ssize_t __print_txpwr_map(struct rtw89_dev *rtwdev, char *buf, size_t buf
else
max_valid_addr = map->addr_to;
- if (max_valid_addr == 0)
+ if (max_valid_addr == 0) {
+ vfree(bufp);
return -EOPNOTSUPP;
+ }
for (addr = map->addr_from; addr <= max_valid_addr; addr += 4) {
ret = rtw89_mac_txpwr_read32(rtwdev, RTW89_PHY_0, addr, &val);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Krzysztof Kozlowski @ 2026-01-16 7:48 UTC (permalink / raw)
To: Jeff Johnson, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Jeff Johnson, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, Vinod Koul, Balakrishna Godavarthi,
Matthias Kaehlcke
Cc: linux-arm-msm, linux-kernel, devicetree, linux-bluetooth,
linux-wireless, ath10k, linux-pm, Bartosz Golaszewski
In-Reply-To: <52b2b799-09e6-40a4-bea8-c7e8bf21cf51@oss.qualcomm.com>
On 15/01/2026 23:30, Jeff Johnson wrote:
> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
>> The WCN39xx family of WiFi/BT chips incorporates a simple PMU, spreading
>> voltages over internal rails. Implement support for using powersequencer
>> for this family of ATH10k devices in addition to using regulators.
>>
>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>> ---
>> drivers/net/wireless/ath/ath10k/snoc.c | 54 ++++++++++++++++++++++++++++++++--
>> drivers/net/wireless/ath/ath10k/snoc.h | 2 ++
>
> My automation flagged:
> * drivers/net/wireless/ath/ath10k/snoc.c has no QTI copyright
> * drivers/net/wireless/ath/ath10k/snoc.h has no QTI copyright
> * 2 copyright issues
>
> I'll add these manually in my 'pending' branch
>
And why is this a problem? You are not here to impose Qualcomm rules, bu
care about Linux kernel. You cannot add copyrights based on what exactly?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH ath-next v5 0/6] wifi: ath11k: Add single shot/periodic CFR capture support
From: Jeff Johnson @ 2026-01-16 5:35 UTC (permalink / raw)
To: Qian Zhang, Baochen Qiang, ath11k; +Cc: linux-wireless, Yu Zhang
In-Reply-To: <0f4fa27e-d9b4-4a23-8c8d-53f4a7014167@oss.qualcomm.com>
On 1/15/2026 3:47 PM, Qian Zhang wrote:
>
>
> On 1/15/2026 12:55 AM, Jeff Johnson wrote:
>> On 1/5/2026 3:51 AM, Qian Zhang wrote:
>>> On 1/5/2026 10:22 AM, Baochen Qiang wrote:
>>>> On 12/30/2025 4:25 PM, Qian Zhang wrote:
>>>> what are these dependencies? They are not present in old revisions.
>>>>
>>>> BTW, if you indeed has dependencies, in addition to these prerequisite-patch-id's, please
>>>> also list them explicitly in the cover letter above.
>>>>
>>>
>>> These dependency details were added by mistake, and I will remove them.
>>
>> Was that the only known problem with the v5 series?
>>
>> My automation flagged a checkpatch issue in the 6/6 patch:
>> WARNING:LINE_SPACING: Missing a blank line after declarations
>>
>> If there are no other issues with v5 then I can fix this in my pending branch.
>> Or you can submit a v6. Just let me know.
>>
>> /jeff
>
> This feature is under LX test now.
> Patchset V6 will be submitted when testing is finished.
> Fixes for new issues (if any new issue are found) as well
> as all previous reviewer comments will be included in
> the v6 patchset.
>
> Qian
I already had this in my pending queue and pushed it to ath-next before I saw
your message. So any fixes would need to be separate patches beyond what has
been merged in ath-next.
/jeff
^ permalink raw reply
* Re: [PATCH wireless-next v2 1/3] wifi: cfg80211: Add support for S1G Response Indication Configuration
From: Ria Thomas @ 2026-01-16 5:31 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless, lachlan.hodges, arien.judge, pradeep.reddy, simon
In-Reply-To: <048c2715d08822d7f79b082cbe332f982d8ced61.camel@sipsolutions.net>
On Tue, Jan 13, 2026 at 09:50:44AM +0100, Johannes Berg wrote:
>
> Actually, reading the spec, are you sure it's even on an *interface*
> scope? A lot of this seems to me like it should be per intended
> receiver, and you need to know its capabilities for generating the
> intended response?
>
After reviewing the IEEE 802.11ah specification and correlating it with
the WFA HaLow certification tests, it is clear that Response Indication
is not intended to be a per-receiver or per-peer configuration.
Per IEEE Std 802.11-2024, 10.3.2.17, Response Indication is a
TXVECTOR parameter set by the transmitting MAC entity (AP or STA)
to advertise the expected response type for a specific PPDU and to
protect the corresponding response PPDU expected SIFS later. As a
TXVECTOR parameter, Response Indication is selected for each
transmission and applies at the PPDU level; it is not defined
as persistent state associated with a specific peer STA.
The selection of a Response Indication value is governed by
the established BSS context and the protocol rules defined by
the standard for when a response is expected, rather than by
any explicit per-peer Response Indication capability negotiation.
Accordingly, the implementation treats Response Indication as a
per-interface (per MAC/VIF) transmit configuration, applied when
constructing the TXVECTOR for each PPDU. Response Indication therefore
remains a local, per-transmission decision, governed by the applicable
protocol rules and operating context, rather than by persistent per-receiver
configuration.
I hope this clarifies the rationale behind the current approach.
I am happy to discuss further if there are specific scenarios you would
like to examine.
Ria
^ permalink raw reply
* Re: [PATCH v2 04/14] wifi: ath10k: snoc: support powering on the device via pwrseq
From: Dmitry Baryshkov @ 2026-01-16 2:57 UTC (permalink / raw)
To: Jeff Johnson
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Jeff Johnson, Bjorn Andersson,
Konrad Dybcio, Manivannan Sadhasivam, Vinod Koul,
Balakrishna Godavarthi, Matthias Kaehlcke, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath10k,
linux-pm, Krzysztof Kozlowski, Bartosz Golaszewski
In-Reply-To: <6db7a42e-7f12-499b-b36e-687ec93b2e62@oss.qualcomm.com>
On Thu, Jan 15, 2026 at 03:12:19PM -0800, Jeff Johnson wrote:
> On 1/5/2026 5:01 PM, Dmitry Baryshkov wrote:
> > @@ -1023,9 +1024,15 @@ static int ath10k_hw_power_on(struct ath10k *ar)
> >
> > ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power on\n");
> >
> > + if (ar_snoc->pwrseq) {
> > + ret = pwrseq_power_on(ar_snoc->pwrseq);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > ret = regulator_bulk_enable(ar_snoc->num_vregs, ar_snoc->vregs);
> > if (ret)
> > - return ret;
> > + goto pwrseq_off;
> >
> > ret = clk_bulk_prepare_enable(ar_snoc->num_clks, ar_snoc->clks);
> > if (ret)
> > @@ -1035,18 +1042,28 @@ static int ath10k_hw_power_on(struct ath10k *ar)
> >
> > vreg_off:
> > regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> > +pwrseq_off:
> > + pwrseq_power_off(ar_snoc->pwrseq);
>
> in this function you conditionally call pwrseq_power_on()
> but on error you unconditionally call pwrseq_power_off()
>
> in the below function you conditionally call pwrseq_power_off()
>
> so there is inconsistency.
>
> note that both pwrseq_power_on() and pwrseq_power_off() handle a NULL
> pwrseq_desc so is there any reason to not just call both both functions
> unconditionally everywhere?
Indeed, it should not be necessary. I'll send a new iteration (and also
update the copyright).
>
> > +
> > return ret;
> > }
> >
> > static int ath10k_hw_power_off(struct ath10k *ar)
> > {
> > struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar);
> > + int ret_seq = 0;
> > + int ret_vreg;
> >
> > ath10k_dbg(ar, ATH10K_DBG_SNOC, "soc power off\n");
> >
> > clk_bulk_disable_unprepare(ar_snoc->num_clks, ar_snoc->clks);
> >
> > - return regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> > + ret_vreg = regulator_bulk_disable(ar_snoc->num_vregs, ar_snoc->vregs);
> > +
> > + if (ar_snoc->pwrseq)
> > + ret_seq = pwrseq_power_off(ar_snoc->pwrseq);
> > +
> > + return ret_vreg ? : ret_seq;
> > }
> >
> > static void ath10k_snoc_wlan_disable(struct ath10k *ar)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH ath-next v2 00/18] wifi: ath12k: add support for QCC2072
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: Jeff Johnson, Baochen Qiang; +Cc: linux-wireless, ath12k, Miaoqing Pan
In-Reply-To: <20260112-ath12k-support-qcc2072-v2-0-fc8ce1e43969@oss.qualcomm.com>
On Mon, 12 Jan 2026 15:36:20 +0800, Baochen Qiang wrote:
> QCC2072 is a PCI based device that is very much like WCN7850, the major
> difference is that QCC2072 has only one phy hence does not support DBS.
> Due to such similarity, lots of existing WCN7850 code can be leveraged.
> While to handle the difference, separate operation is added, necessary
> configuration is changed.
>
> Overview:
> - The first 6 patches refactor/fix current code base to prepare for QCC2072
> support.
> - Patches [7,8/18] add hardware registers and parameters for QCC2072.
> - Patches [9,10/18] add support for new QMI memory type, new firmware
> download etc, these are specific to QCC2072 hence necessary configs are
> added to make sure other chips are not affected.
> - Patches [11,12/18] add new callbacks for QCC2072. These callbacks are
> actually taken from WCN7850, with modifications due to the different
> HAL descriptors.
> - Patches [13,14/18] add 32 bits variants for QCC2072 REO CMD/status ring
> handling, as existing 64 bits functions don't work with QCC2072.
> - Patches [15,16/18] contains changes required by QCC2072, but those
> changes are made common to all chips. They are not expected to cause
> any regression.
> - Patch [17/18] add QRTR node id register such that QCC2072 can work when
> firmware-2.bin image is used.
> - The last patch enables QCC2072 support.
>
> [...]
Applied, thanks!
[01/18] wifi: ath12k: refactor PCI window register access
commit: 7a6b6386deb71908181adc26c6ddbe9bc6cef169
[02/18] wifi: ath12k: refactor REO CMD ring handling
commit: 9615a6727e9d836e60dd4c7442bc8c16f0382203
[03/18] wifi: ath12k: refactor REO status ring handling
commit: 1f165022d5f06a420a2257d7c38e3d19e16ef071
[04/18] wifi: ath12k: fix preferred hardware mode calculation
commit: 7f852de0003219c431a6f2ffd951fd82a4673660
[05/18] wifi: ath12k: refactor 320 MHz bandwidth support parsing
commit: 6281d4f4df228b3588eeb3186d97e195fed07d35
[06/18] wifi: ath12k: fix mac phy capability parsing
commit: b5151c9b6e3a347416a4b4b55fc00195526d8771
[07/18] wifi: ath12k: add hardware registers for QCC2072
commit: 089e0e746d598b5d305dae366e022dd90e1bd4f2
[08/18] wifi: ath12k: add hardware parameters for QCC2072
commit: 12048e2c052b1992857fb71a86d13e0e5b65e5da
[09/18] wifi: ath12k: support LPASS_SHARED target memory type
commit: 68cc3ac88118ee9ab797aadf15dd30a8145b4be7
[10/18] wifi: ath12k: support downloading auxiliary ucode image for QCC2072
commit: b065ccf4193ed5f0c224b53fc2cb829a0e2b701e
[11/18] wifi: ath12k: add HAL descriptor and ops for QCC2072
commit: 28badc78142e4750136ae51da474cdc150a8b3ff
[12/18] wifi: ath12k: add hardware ops support for QCC2072
commit: 023ace9f9232d43137f346d908996a6fee4de70a
[13/18] wifi: ath12k: handle REO CMD ring for QCC2072
commit: b7ffeb0f62fddc5f21c6ff610d28e08247b6b9b5
[14/18] wifi: ath12k: handle REO status ring for QCC2072
commit: 37b34a1c545aa2ab94f3ce1aceec3f00d6f8e039
[15/18] wifi: ath12k: limit number of channels per WMI command
commit: d518b2d601acffdea6d50ff951cb1344a4807976
[16/18] wifi: ath12k: send peer meta data version to firmware
commit: d6c5d412f60007e23bebc4eba1de2530a7651962
[17/18] wifi: ath12k: fix PCIE_LOCAL_REG_QRTR_NODE_ID definition for QCC2072
commit: 853deed04be384fde9138e0442630b5bddf2e418
[18/18] wifi: ath12k: enable QCC2072 support
commit: d8e1f4a193101a72235416f189b01131a57e26e9
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3] wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_params
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: jjohnson, ath11k, Alexandru Gagniuc
Cc: baochen.qiang, linux-wireless, linux-kernel
In-Reply-To: <20251228151408.2116108-1-mr.nuke.me@gmail.com>
On Sun, 28 Dec 2025 09:14:05 -0600, Alexandru Gagniuc wrote:
> ".max_tx_ring" is an upper bounds to indexing ".tcl2wbm_rbm_map". It
> is initialized in, core.c, a different file than the array. This
> spaghetti-like relation is fragile and not obvious. Accidentally
> setting ".max_tx_ring" too high leads to a hard to track out-of-
> bounds access and memory corruption.
>
> There is a small ambiguity on the meaning of "max_tx_ring":
> - The highest ring, max=3 implies there are 4 rings (0, 1, 2, 3)
> - The highest number to use for array indexing (there are 3 rings)
>
> [...]
Applied, thanks!
[1/1] wifi: ath11k: move .max_tx_ring to struct ath11k_hw_hal_params
commit: b515730ec3d231aa36b6177524532fc7d94f1750
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH next] wifi: ath12k: clean up on error in ath12k_dp_setup()
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: Harsh Kumar Bijlani, Dan Carpenter
Cc: Jeff Johnson, Ripan Deuri, Vasanthakumar Thiagarajan,
Baochen Qiang, linux-wireless, ath12k, linux-kernel,
kernel-janitors
In-Reply-To: <aUOw1J0TU4VgeXj6@stanley.mountain>
On Thu, 18 Dec 2025 10:44:20 +0300, Dan Carpenter wrote:
> Destroy the rhash_tbl before returning the error code.
>
>
Applied, thanks!
[1/1] wifi: ath12k: clean up on error in ath12k_dp_setup()
commit: 40feb23c726369700918b9c35db987f9fe3c6498
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next] ath5k: debug.h: fix enum ath5k_debug_level kernel-doc
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: netdev, Randy Dunlap
Cc: Jiri Slaby, Nick Kossifidis, Luis Chamberlain, Johannes Berg,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-wireless
In-Reply-To: <20251128010401.546506-1-rdunlap@infradead.org>
On Thu, 27 Nov 2025 17:04:01 -0800, Randy Dunlap wrote:
> Add a description for ATH5K_DEBUG_ANI and delete the descriptions for
> 3 undefined enum descriptions to prevent these warnings:
>
> Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Enum value
> 'ATH5K_DEBUG_ANI' not described in enum 'ath5k_debug_level'
> Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Excess enum value
> '%ATH5K_DEBUG_DUMP_RX' description in 'ath5k_debug_level'
> Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Excess enum value
> '%ATH5K_DEBUG_DUMP_TX' description in 'ath5k_debug_level'
> Warning: drivers/net/wireless/ath/ath5k/debug.h:111 Excess enum value
> '%ATH5K_DEBUG_TRACE' description in 'ath5k_debug_level'
>
> [...]
Applied, thanks!
[1/1] ath5k: debug.h: fix enum ath5k_debug_level kernel-doc
commit: b1e542b6f0775d35bf546f3de33644b4f761fc3c
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: do WoW offloads only on primary link
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: Jeff Johnson, Baochen Qiang; +Cc: linux-wireless, ath12k
In-Reply-To: <20251103-ath12-primary-link-wow-v1-1-3cf523dc09f0@oss.qualcomm.com>
On Mon, 03 Nov 2025 10:44:49 +0800, Baochen Qiang wrote:
> In case of multi-link connection, WCN7850 firmware crashes due to WoW
> offloads enabled on both primary and secondary links.
>
> Change to do it only on primary link to fix it.
>
> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: do WoW offloads only on primary link
commit: e62102ac9b773bdb08475aa9ca24dea61ae98708
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] ath: wil6210: fix a bunch of kernel-doc warnings
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: netdev, Randy Dunlap; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20251117020213.443126-1-rdunlap@infradead.org>
On Sun, 16 Nov 2025 18:02:13 -0800, Randy Dunlap wrote:
> scripts/kernel-doc.py reports 51 kernel-doc warnings in wil6210.h.
> Fix all kernel-doc warnings reported in wil6210.h.
>
> Several comments are changed from "/**" to "/*" since it appears that
> "/**" was used for many non-kernel-doc comments.
>
> - add kernel-doc for missing function parameters
> - add one function "Returns:"
> - correct kernel-doc struct name to match actual struct name in 2 places
>
> [...]
Applied, thanks!
[1/1] ath: wil6210: fix a bunch of kernel-doc warnings
commit: dec6a3c6d6dfc6402118529de230e76e65df9a9b
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2] wifi: ath12k: remove redundant pci_set_drvdata() call
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: ath12k, Alexander Minchev; +Cc: linux-wireless, Baochen Qiang
In-Reply-To: <20251127072839.14167-2-adminchev@proton.me>
On Thu, 27 Nov 2025 07:29:37 +0000, Alexander Minchev wrote:
> pci_set_drvdata() is called twice in ath12k_pci_probe() with the
> same pointer. Remove the earlier call so drvdata is set after
> ath12k_base and ath12k_pci initialization is complete.
>
> Having two calls might suggest that drvdata needs to be set early for
> some reason, even though it is not used until after the 'ab' struct
> ath12k_base is fully populated. Even though exact placement is
> not critical, keeping a single pci_set_drvdata() at the end of
> the initialization makes it clearer that drvdata points to a
> fully initialized structure and avoids confusion for future changes.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: remove redundant pci_set_drvdata() call
commit: 8fb264d1a0c5b3feae5f492ee2bc2997b71b63e3
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v5 0/6] wifi: ath11k: Add single shot/periodic CFR capture support
From: Jeff Johnson @ 2026-01-16 1:26 UTC (permalink / raw)
To: ath11k, Qian Zhang; +Cc: linux-wireless, Yu Zhang
In-Reply-To: <20251230082520.3401007-1-qian.zhang@oss.qualcomm.com>
On Tue, 30 Dec 2025 13:55:14 +0530, Qian Zhang wrote:
> To enable/disable cfr feature use command,
>
> echo <val> > /sys/kernel/debug/ieee80211/phyX/ath11k/enable_cfr
>
> where, val: 0 to disable CFR and 1 to enable CFR.
>
> To enable CFR capture for associated peers,
>
> [...]
Applied, thanks!
[1/6] wifi: ath11k: Add initialization and deinitialization sequence for CFR module
commit: 9b2e3b4ebec7f23a552de4ee6f2e5da8028a2920
[2/6] wifi: ath11k: Register debugfs for CFR configuration
commit: 9754d4ba4df7e63ab271abb8190008c3a4dfcd26
[3/6] wifi: ath11k: Add support unassociated client CFR
commit: b3d43d890399e4f49f31d90083bfe9b349cce6dc
[4/6] wifi: ath11k: Register relayfs entries for CFR dump
commit: c1bf6959dd81949ebcdeef53fbc9bfff91ec241a
[5/6] wifi: ath11k: Register DBR event handler for CFR data
commit: 99cf756831d203fcdd3f9a8833355fb86611a1f2
[6/6] wifi: ath11k: Register handler for CFR capture event
commit: ca765beda7084ebad7630bc403bc0b2598d34e98
Best regards,
--
Jeff Johnson <jeff.johnson@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