* [PATCH] wifi: ath9k: validate RX stream lengths before copying
From: Pengpeng Hou @ 2026-07-01 5:38 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Pengpeng Hou, linux-wireless, linux-kernel
ath9k_hif_usb_rx_stream() reads RX stream headers and copies payload
bytes from the current skb into newly allocated skbs. It also completes
packets that span two URBs by copying the remaining bytes from the next
skb into hif_dev->remain_skb.
The parser checked the stream tag and an upper bound on pkt_len, but it
did not first prove that the fixed header, the non-fragmented payload,
or the bytes needed to complete a fragmented packet are present in the
current skb. Reject malformed RX stream data before reading or copying
beyond the received buffer.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 821909b8..f47b0ae0 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -571,6 +571,16 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
ptr = (u8 *) remain_skb->data;
index = rx_remain_len;
+ if (rx_remain_len < hif_dev->rx_pad_len ||
+ len < rx_remain_len - hif_dev->rx_pad_len) {
+ dev_kfree_skb_any(remain_skb);
+ hif_dev->remain_skb = NULL;
+ hif_dev->rx_remain_len = 0;
+ RX_STAT_INC(hif_dev, skb_dropped);
+ spin_unlock(&hif_dev->rx_lock);
+ return;
+ }
+
rx_remain_len -= hif_dev->rx_pad_len;
ptr += rx_pkt_len;
@@ -597,6 +607,11 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
ptr = (u8 *) skb->data;
+ if (len - index < 4) {
+ RX_STAT_INC(hif_dev, skb_dropped);
+ goto invalid_pkt;
+ }
+
pkt_len = get_unaligned_le16(ptr + index);
pkt_tag = get_unaligned_le16(ptr + index + 2);
@@ -625,6 +640,11 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
index = index + 4 + pkt_len + pad_len;
if (index > MAX_RX_BUF_SIZE) {
+ if (len < MAX_RX_BUF_SIZE) {
+ RX_STAT_INC(hif_dev, skb_dropped);
+ goto invalid_pkt;
+ }
+
spin_lock(&hif_dev->rx_lock);
nskb = __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC);
if (!nskb) {
@@ -649,6 +669,11 @@ static void ath9k_hif_usb_rx_stream(struct hif_device_usb *hif_dev,
hif_dev->remain_skb = nskb;
spin_unlock(&hif_dev->rx_lock);
} else {
+ if (pkt_len > len - chk_idx - 4) {
+ RX_STAT_INC(hif_dev, skb_dropped);
+ goto invalid_pkt;
+ }
+
if (pool_index == MAX_PKT_NUM_IN_TRANSFER) {
dev_err(&hif_dev->udev->dev,
"ath9k_htc: over RX MAX_PKT_NUM\n");
^ permalink raw reply related
* Re: [PATCH v8 07/14] remoteproc: qcom: Select QCOM_PAS generic service
From: Sumit Garg @ 2026-07-01 5:36 UTC (permalink / raw)
To: Konrad Dybcio
Cc: andersson, linux-arm-msm, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, konradybcio,
robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <64e425ab-dddc-4221-81d3-3283e2961bea@oss.qualcomm.com>
Hi Konrad,
On Tue, Jun 30, 2026 at 02:37:59PM +0200, Konrad Dybcio wrote:
> On 6/26/26 3:34 PM, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Select PAS generic service driver to enable support for multiple PAS
> > backends like OP-TEE in addition to SCM.
> >
> > Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans
> > Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> > drivers/remoteproc/Kconfig | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index c521c744e7db..65befdbfa5f7 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -210,6 +210,7 @@ config QCOM_Q6V5_MSS
> > select QCOM_Q6V5_COMMON
> > select QCOM_RPROC_COMMON
> > select QCOM_SCM
> > + select QCOM_PAS
>
> This is a NOP, SCM already requires QCOM_PAS
That's true but I think we should rather have explicit modules
dependencies whose APIs are being used by their clients. QCOM_SCM is a
special module in this case exporting direct SCM calls apart from being
the backend for the PAS service.
I would prefer explicit dependencies but let me know if you feel
strongly otherwise.
>
> > help
> > Say y here to support the Qualcomm self-authenticating modem
> > subsystem based on Hexagon V5. The TrustZone based system is
> > @@ -230,6 +231,7 @@ config QCOM_Q6V5_PAS
> > select QCOM_Q6V5_COMMON
> > select QCOM_RPROC_COMMON
> > select QCOM_SCM
> > + select QCOM_PAS
>
> Likewise
>
> > help
> > Say y here to support the TrustZone based Peripheral Image Loader for
> > the Qualcomm remote processors. This is commonly used to control
> > @@ -282,7 +284,7 @@ config QCOM_WCNSS_PIL
> > select QCOM_MDT_LOADER
> > select QCOM_PIL_INFO
> > select QCOM_RPROC_COMMON
> > - select QCOM_SCM
> > + select QCOM_PAS
>
> This is OK
>
> _however_
>
> It leads to a situation where no back-ends can be enabled
The TEE backend is enabled by default if ARCH_QCOM is enabled, if you
agree then we can similarly enable SCM backend too.
-Sumit
^ permalink raw reply
* [PATCH] wifi: rsi: avoid reading TKIP MIC keys for non-TKIP ciphers
From: Pengpeng Hou @ 2026-07-01 5:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Pengpeng Hou, linux-kernel
rsi_hal_load_key() copies tx_mic_key and rx_mic_key from data[16] and
data[24] whenever key data is present. Those offsets are only part of
the 32-byte TKIP key layout. Shorter keys used by other ciphers, such as
CCMP, do not provide those bytes, so the unconditional copies can read
past the supplied key buffer.
Only copy the MIC keys for TKIP, and reject malformed TKIP keys that are
shorter than the expected 32-byte layout.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 7f2c1608..af9e997d 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -848,8 +848,14 @@ int rsi_hal_load_key(struct rsi_common *common,
} else {
memcpy(&set_key->key[0][0], data, key_len);
}
- memcpy(set_key->tx_mic_key, &data[16], 8);
- memcpy(set_key->rx_mic_key, &data[24], 8);
+ if (cipher == WLAN_CIPHER_SUITE_TKIP) {
+ if (key_len < 32) {
+ dev_kfree_skb(skb);
+ return -EINVAL;
+ }
+ memcpy(set_key->tx_mic_key, &data[16], 8);
+ memcpy(set_key->rx_mic_key, &data[24], 8);
+ }
} else {
memset(&set_key[FRAME_DESC_SZ], 0, frame_len - FRAME_DESC_SZ);
}
^ permalink raw reply related
* [PATCH ath-next v4] wifi: ath12k: add QMI capability negotiation for dynamic memory mode
From: Aaradhana Sahu @ 2026-07-01 4:16 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, Aaradhana Sahu, Rameshkumar Sundaram,
Baochen Qiang
On AHB platforms, firmware operates in two modes: fixed-memory mode where
firmware uses hardcoded addresses for memory regions such as BDF and does
not request HOST_DDR memory from the host, and dynamic-memory mode where
firmware expects the host to provide memory addresses including HOST_DDR
after the Q6 read-only region and relies on host allocation for all memory
types.
Introduce QMI capability negotiation to support both modes. Add a new QMI
PHY capability flag dynamic_ddr_support which is advertised by firmware to
indicate it supports dynamic memory mode. When the host detects this
capability, set the dynamic_mem_support flag in the host capability message
to signal the host is ready to provide dynamic memory allocation. This
triggers firmware to send the HOST_DDR memory request and use the
host-provided address.
For backward compatibility, if firmware doesn't advertise
dynamic_ddr_support, the firmware continues to operate in fixed-memory mode
where firmware uses predefined addresses.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
---
v4:
-Rebased on ToT.
v3:
-Restored QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN change.
v2:
-Dropped QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN and QMI_WLANFW_PHY_CAP_RESP_MSG_V01_MAX_LEN changes.
-Used %u instead of %d in the debug log.
---
drivers/net/wireless/ath/ath12k/qmi.c | 49 +++++++++++++++++++++++++--
drivers/net/wireless/ath/ath12k/qmi.h | 8 +++--
2 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/qmi.c b/drivers/net/wireless/ath/ath12k/qmi.c
index 1f3efcc16ac3..cabdd544bbc7 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.c
+++ b/drivers/net/wireless/ath/ath12k/qmi.c
@@ -506,6 +506,24 @@ static const struct qmi_elem_info qmi_wlanfw_host_cap_req_msg_v01_ei[] = {
.offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
feature_list),
},
+ {
+ .data_type = QMI_OPT_FLAG,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x33,
+ .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
+ dynamic_mem_support_valid),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x33,
+ .offset = offsetof(struct qmi_wlanfw_host_cap_req_msg_v01,
+ dynamic_mem_support),
+ },
{
.data_type = QMI_EOTI,
.array_type = NO_ARRAY,
@@ -602,6 +620,24 @@ static const struct qmi_elem_info qmi_wlanfw_phy_cap_resp_msg_v01_ei[] = {
.offset = offsetof(struct qmi_wlanfw_phy_cap_resp_msg_v01,
single_chip_mlo_support),
},
+ {
+ .data_type = QMI_OPT_FLAG,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x17,
+ .offset = offsetof(struct qmi_wlanfw_phy_cap_resp_msg_v01,
+ dynamic_ddr_support_valid),
+ },
+ {
+ .data_type = QMI_UNSIGNED_1_BYTE,
+ .elem_len = 1,
+ .elem_size = sizeof(u8),
+ .array_type = NO_ARRAY,
+ .tlv_type = 0x17,
+ .offset = offsetof(struct qmi_wlanfw_phy_cap_resp_msg_v01,
+ dynamic_ddr_support),
+ },
{
.data_type = QMI_EOTI,
.array_type = NO_ARRAY,
@@ -2254,6 +2290,11 @@ int ath12k_qmi_host_cap_send(struct ath12k_base *ab)
if (ret < 0)
goto out;
+ if (ab->qmi.dynamic_ddr_support) {
+ req.dynamic_mem_support_valid = 1;
+ req.dynamic_mem_support = 1;
+ }
+
ret = qmi_txn_init(&ab->qmi.handle, &txn,
qmi_wlanfw_host_cap_resp_msg_v01_ei, &resp);
if (ret < 0)
@@ -2325,11 +2366,15 @@ static void ath12k_qmi_phy_cap_send(struct ath12k_base *ab)
ab->qmi.num_radios = resp.num_phy;
+ if (resp.dynamic_ddr_support_valid)
+ ab->qmi.dynamic_ddr_support = resp.dynamic_ddr_support;
+
ath12k_dbg(ab, ATH12K_DBG_QMI,
- "phy capability resp valid %u single_chip_mlo_support %u valid %u num_phy %u valid %u board_id %u\n",
+ "phy capability resp valid %u single_chip_mlo_support %u valid %u num_phy %u valid %u board_id %u dynamic_ddr_valid %u dynamic_ddr_support %u\n",
resp.single_chip_mlo_support_valid, resp.single_chip_mlo_support,
resp.num_phy_valid, resp.num_phy,
- resp.board_id_valid, resp.board_id);
+ resp.board_id_valid, resp.board_id, resp.dynamic_ddr_support_valid,
+ resp.dynamic_ddr_support);
return;
diff --git a/drivers/net/wireless/ath/ath12k/qmi.h b/drivers/net/wireless/ath/ath12k/qmi.h
index 80a9b42a2548..cbe5be30053a 100644
--- a/drivers/net/wireless/ath/ath12k/qmi.h
+++ b/drivers/net/wireless/ath/ath12k/qmi.h
@@ -153,9 +153,10 @@ struct ath12k_qmi {
struct m3_mem_region aux_uc_mem;
unsigned int service_ins_id;
struct dev_mem_info dev_mem[ATH12K_QMI_WLFW_MAX_DEV_MEM_NUM_V01];
+ u8 dynamic_ddr_support;
};
-#define QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN 261
+#define QMI_WLANFW_HOST_CAP_REQ_MSG_V01_MAX_LEN 265
#define QMI_WLANFW_HOST_CAP_REQ_V01 0x0034
#define QMI_WLFW_MAX_NUM_GPIO_V01 32
#define QMI_WLANFW_MAX_PLATFORM_NAME_LEN_V01 64
@@ -253,7 +254,8 @@ struct qmi_wlanfw_host_cap_req_msg_v01 {
struct wlfw_host_mlo_chip_info_s_v01 mlo_chip_info[QMI_WLFW_MAX_NUM_MLO_CHIPS_V01];
u8 feature_list_valid;
u64 feature_list;
-
+ u8 dynamic_mem_support_valid;
+ u8 dynamic_mem_support;
};
struct qmi_wlanfw_host_cap_resp_msg_v01 {
@@ -274,6 +276,8 @@ struct qmi_wlanfw_phy_cap_resp_msg_v01 {
u32 board_id;
u8 single_chip_mlo_support_valid;
u8 single_chip_mlo_support;
+ u8 dynamic_ddr_support_valid;
+ u8 dynamic_ddr_support;
};
#define QMI_WLANFW_IND_REGISTER_REQ_MSG_V01_MAX_LEN 54
base-commit: 68151ce3373843fa89490d2d92f0497c4877c845
--
2.34.1
^ permalink raw reply related
* Re: [PATCH ath-next v3] wifi: ath12k: add QMI capability negotiation for dynamic memory mode
From: Aaradhana Sahu @ 2026-07-01 3:15 UTC (permalink / raw)
To: Jeff Johnson, ath12k; +Cc: linux-wireless
In-Reply-To: <4db87d04-2de6-4521-8da0-d80b036d216a@oss.qualcomm.com>
On 6/30/2026 9:23 PM, Jeff Johnson wrote:
> On 6/26/2026 1:43 AM, Aaradhana Sahu wrote:
>> @@ -2319,11 +2360,14 @@ static void ath12k_qmi_phy_cap_send(struct ath12k_base *ab)
>>
>> ab->qmi.num_radios = resp.num_phy;
>>
>> + if (resp.dynamic_ddr_support_valid)
>> + ab->qmi.dynamic_ddr_support = resp.dynamic_ddr_support;
>> +
>> ath12k_dbg(ab, ATH12K_DBG_QMI,
>> - "phy capability resp valid %d single_chip_mlo_support %d valid %d num_phy %d valid %d board_id %d\n",
>> + "phy capability resp valid %d single_chip_mlo_support %d valid %d num_phy %d valid %d board_id %d dynamic_ddr_valid %u dynamic_ddr_support %u\n",
>> resp.single_chip_mlo_support_valid, resp.single_chip_mlo_support,
>> - resp.num_phy_valid, resp.num_phy,
>> - resp.board_id_valid, resp.board_id);
>> + resp.num_phy_valid, resp.num_phy, resp.board_id_valid, resp.board_id,
>> + resp.dynamic_ddr_support_valid, resp.dynamic_ddr_support);
>
> Your logging change conflicts with the one in:
> wifi: ath12k: use %u for unsigned variables in QMI debug logs
>
> That one is already in my pending queue, so I'll have you rebase once that one
> lands in ath-next.
>
> /jeff
>
Sure, I will rebase and send next version.
^ permalink raw reply
* Atheros AR9280 / AR7010 Initial low scaning signal range
From: cybersnow_2001 @ 2026-07-01 2:08 UTC (permalink / raw)
To: Linux Wireless
I'm using an Atheros AR9280 USB dongle (Panasonic UB94) under linux. I think a few years ago, it wasn't doing this behavior but now, I think it's starting to be a serious issue. When I plug the USB Wifi key, I can only see a few Access points but not all. Even near the main AP, the signal is seen as very low (1 bar out of 5). Sometimes, I cannot even see it. When trying to connect to it, it connects hardly. But after a few minutes, the signal becomes strong and all the neighborhood AP are shown. When the AP advertise the right TXPower, it seems to fix all the issues. The others AP appear and the signal become stronger on the actual connection. I see the signal jumping from 30% to 70% and the RX Rate jump too.
I suspect the ath9k_htc module is not enforcing a high enough TX Power at first glance or something else happening I don't understand with this chipset... The country code is set at 00 at first USB connection. But until I connect to an AP, the AR9280 stays at a low power state and on this country ID 00. Also, it's like the 5Ghz network scanning isn't activated. I don't know...
I've read in another forum that people experienced the same issue after a kernel update, maybe after 6.8. What do you think?
^ permalink raw reply
* [PATCH ath-next] wifi: ath11k: cap out-of-range rx MCS instead of leaving bogus rate
From: Baochen Qiang @ 2026-07-01 1:49 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless, ath11k, Baochen Qiang
ath11k can receive HT/VHT/HE frames whose reported MCS is above the
maximum that can be expressed in the corresponding mac80211 rate space
(e.g. an HE frame reported with MCS 12, while HE tops out at MCS 11).
The frame itself is valid and decodes correctly, but for such a frame
ath11k_dp_rx_h_rate() leaves rx_status->rate_idx set to the out-of-range
value and never assigns rx_status->encoding, so it stays RX_ENC_LEGACY
from the ath11k_dp_rx_h_ppdu() initialization. Once that frame reaches
mac80211 it trips the rate sanity check and the frame is dropped with a
splat:
ath11k_pci 0000:03:00.0: Received with invalid mcs in HE mode 12
WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:5433 ieee80211_rx_list+0xb0a/0xe90 [mac80211]
Dropping the frame would discard otherwise valid data, so instead cap the
reported MCS to the maximum the rate space can express and deliver the
frame. Set rx_status->encoding before the range check and assign rate_idx
from the capped value, so a frame with an out-of-range MCS no longer
leaves partial or bogus rate metadata behind. Also downgrade the logging
level since they are not treated as invalid frames now. The only loss is
that such a frame is reported as the capped MCS in the rx rate statistics.
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath11k/dp_rx.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/dp_rx.c b/drivers/net/wireless/ath/ath11k/dp_rx.c
index 9e90d8e3f155..896d30181754 100644
--- a/drivers/net/wireless/ath/ath11k/dp_rx.c
+++ b/drivers/net/wireless/ath/ath11k/dp_rx.c
@@ -2334,10 +2334,10 @@ static void ath11k_dp_rx_h_rate(struct ath11k *ar, struct hal_rx_desc *rx_desc,
case RX_MSDU_START_PKT_TYPE_11N:
rx_status->encoding = RX_ENC_HT;
if (rate_mcs > ATH11K_HT_MCS_MAX) {
- ath11k_warn(ar->ab,
- "Received with invalid mcs in HT mode %d\n",
- rate_mcs);
- break;
+ ath11k_dbg(ar->ab, ATH11K_DBG_DP_RX,
+ "Received HT frame with out-of-range mcs %d, capping to %d\n",
+ rate_mcs, ATH11K_HT_MCS_MAX);
+ rate_mcs = ATH11K_HT_MCS_MAX;
}
rx_status->rate_idx = rate_mcs + (8 * (nss - 1));
if (sgi)
@@ -2346,13 +2346,13 @@ static void ath11k_dp_rx_h_rate(struct ath11k *ar, struct hal_rx_desc *rx_desc,
break;
case RX_MSDU_START_PKT_TYPE_11AC:
rx_status->encoding = RX_ENC_VHT;
- rx_status->rate_idx = rate_mcs;
if (rate_mcs > ATH11K_VHT_MCS_MAX) {
- ath11k_warn(ar->ab,
- "Received with invalid mcs in VHT mode %d\n",
- rate_mcs);
- break;
+ ath11k_dbg(ar->ab, ATH11K_DBG_DP_RX,
+ "Received VHT frame with out-of-range mcs %d, capping to %d\n",
+ rate_mcs, ATH11K_VHT_MCS_MAX);
+ rate_mcs = ATH11K_VHT_MCS_MAX;
}
+ rx_status->rate_idx = rate_mcs;
rx_status->nss = nss;
if (sgi)
rx_status->enc_flags |= RX_ENC_FLAG_SHORT_GI;
@@ -2362,14 +2362,14 @@ static void ath11k_dp_rx_h_rate(struct ath11k *ar, struct hal_rx_desc *rx_desc,
rx_status->enc_flags |= RX_ENC_FLAG_LDPC;
break;
case RX_MSDU_START_PKT_TYPE_11AX:
- rx_status->rate_idx = rate_mcs;
+ rx_status->encoding = RX_ENC_HE;
if (rate_mcs > ATH11K_HE_MCS_MAX) {
- ath11k_warn(ar->ab,
- "Received with invalid mcs in HE mode %d\n",
- rate_mcs);
- break;
+ ath11k_dbg(ar->ab, ATH11K_DBG_DP_RX,
+ "Received HE frame with out-of-range mcs %d, capping to %d\n",
+ rate_mcs, ATH11K_HE_MCS_MAX);
+ rate_mcs = ATH11K_HE_MCS_MAX;
}
- rx_status->encoding = RX_ENC_HE;
+ rx_status->rate_idx = rate_mcs;
rx_status->nss = nss;
rx_status->he_gi = ath11k_mac_he_gi_to_nl80211_he_gi(sgi);
rx_status->bw = ath11k_mac_bw_to_mac80211_bw(bw);
---
base-commit: df81349fece7e61084feae04f301a5655c710c49
change-id: 20260609-ath11k-invalid-he-mcs-25575cfa3713
Best regards,
--
Baochen Qiang <baochen.qiang@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH v6 1/1] wifi: mt76: mt792x: fix use-after-free in mt76_rx_poll_complete
From: Eason Lai @ 2026-07-01 1:06 UTC (permalink / raw)
To: nbd, lorenzo
Cc: linux-wireless, linux-mediatek, Yf.Luo, kun.wu, deren.wu,
sean.wang, quan.zhou, ryder.lee, leon.yen, litien.chang, jb.tsai,
eason.lai, Eason Lai
From: Eason Lai <Eason.Lai@mediatek.com>
A use-after-free issue occurs in mt76_rx_poll_complete due to a race
condition. The STA has already been removed, but the rx_status still
had a pointer to the wcid in the STA.
Set the links' wcid pointers to be NULL for a MLD in
mt7925_sta_pre_rcu_remove()
BUG: KASAN: invalid-access in mt76_rx_poll_complete+0x280/0x470
Call trace:
dump_backtrace+0xec/0x128
show_stack+0x18/0x28
dump_stack_lvl+0x40/0xc8
print_report+0x1b8/0x710
kasan_report+0xe0/0x144
do_bad_area+0x120/0x260
do_tag_check_fault+0x20/0x34
do_mem_abort+0x54/0xa8
el1_abort+0x3c/0x5c
el1h_64_sync_handler+0x40/0xcc
el1h_64_sync+0x7c/0x80
mt76_rx_poll_complete+0x280/0x470
mt76_dma_rx_poll+0x114/0x51c
mt792x_poll_rx+0x60/0xf8
napi_threaded_poll_loop+0xe0/0x450
napi_threaded_poll+0x80/0x9c
kthread+0x11c/0x158
ret_from_fork+0x10/0x20
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Eason Lai <Eason.Lai@mediatek.com>
---
v2: fix mt76x02 build errors
v3: fix mt76x02 build error due to variable set but not used
v4: fix use-after-free in MLO
v5: correct commit message
v6: correct commit message
---
.../net/wireless/mediatek/mt76/mt7925/main.c | 36 ++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
index 73d3722739d0..e3fb6392eda2 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
@@ -2410,6 +2410,40 @@ static void mt7925_channel_switch_rx_beacon(struct ieee80211_hw *hw,
}
}
+static void mt7925_sta_pre_rcu_remove(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct mt76_phy *phy = hw->priv;
+ struct mt76_dev *dev = phy->dev;
+ struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
+
+ mutex_lock(&dev->mutex);
+ spin_lock_bh(&dev->status_lock);
+
+ if (ieee80211_vif_is_mld(vif)) {
+ struct mt792x_sta *msta = (struct mt792x_sta *)sta->drv_priv;
+ struct mt792x_vif *mvif = (struct mt792x_vif *)vif->drv_priv;
+ unsigned long valid = mvif->valid_links;
+ struct mt792x_link_sta *mlink;
+ unsigned int link_id;
+
+ for_each_set_bit(link_id, &valid, IEEE80211_MLD_MAX_NUM_LINKS) {
+ mlink = mt792x_sta_to_link(msta, link_id);
+ if (!mlink || !mlink->wcid.sta)
+ continue;
+ if (mlink->wcid.idx < ARRAY_SIZE(dev->wcid))
+ rcu_assign_pointer(dev->wcid[mlink->wcid.idx],
+ NULL);
+ }
+ } else {
+ rcu_assign_pointer(dev->wcid[wcid->idx], NULL);
+ }
+
+ spin_unlock_bh(&dev->status_lock);
+ mutex_unlock(&dev->mutex);
+}
+
const struct ieee80211_ops mt7925_ops = {
.tx = mt792x_tx,
.start = mt7925_start,
@@ -2422,7 +2456,7 @@ const struct ieee80211_ops mt7925_ops = {
.start_ap = mt7925_start_ap,
.stop_ap = mt7925_stop_ap,
.sta_state = mt76_sta_state,
- .sta_pre_rcu_remove = mt76_sta_pre_rcu_remove,
+ .sta_pre_rcu_remove = mt7925_sta_pre_rcu_remove,
.set_key = mt7925_set_key,
.sta_set_decap_offload = mt7925_sta_set_decap_offload,
#if IS_ENABLED(CONFIG_IPV6)
--
2.45.2
^ permalink raw reply related
* Re: [PATCH 4/4] usb: fix UAF when probe runs concurrent to dyn ID removal
From: Danilo Krummrich @ 2026-06-30 21:55 UTC (permalink / raw)
To: Gary Guo
Cc: Greg Kroah-Hartman, Rafael J. Wysocki,
Toke Høiland-Jørgensen, Johan Hovold, linux-wireless,
linux-kernel, linux-usb, driver-core
In-Reply-To: <20260630-usb_dyn_id_uaf-v1-4-160a02be5ac2@garyguo.net>
On Tue Jun 30, 2026 at 1:38 PM CEST, Gary Guo wrote:
> @@ -320,7 +321,8 @@ static int usb_probe_interface(struct device *dev)
> struct usb_driver *driver = to_usb_driver(dev->driver);
> struct usb_interface *intf = to_usb_interface(dev);
> struct usb_device *udev = interface_to_usbdev(intf);
> - const struct usb_device_id *id;
> + struct usb_device_id id;
> + const struct usb_device_id *matched_id;
> int error = -ENODEV;
> int lpm_disable_error = -ENODEV;
>
> @@ -340,11 +342,12 @@ static int usb_probe_interface(struct device *dev)
> return error;
> }
>
> - id = usb_match_dynamic_id(intf, driver);
> - if (!id)
> - id = usb_match_id(intf, driver->id_table);
> - if (!id)
> - return error;
> + if (!usb_match_dynamic_id(intf, driver, &id)) {
> + matched_id = usb_match_id(intf, driver->id_table);
> + if (!matched_id)
> + return error;
> + id = *matched_id;
> + }
I think this could just be:
struct usb_device_id id_copy;
if (usb_match_dynamic_id(intf, driver, &id_copy)) {
id = &id_copy;
} else {
id = usb_match_id(intf, driver->id_table);
if (!id)
return error;
}
Avoids the unnecessary copy and also results in a smaller diff.
^ permalink raw reply
* Re: [PATCH 3/4] usb: serial: spcp8x5: don't keep usb_device_id
From: Danilo Krummrich @ 2026-06-30 21:52 UTC (permalink / raw)
To: Gary Guo
Cc: Greg Kroah-Hartman, Rafael J. Wysocki,
Toke Høiland-Jørgensen, Johan Hovold, linux-wireless,
linux-kernel, linux-usb, driver-core
In-Reply-To: <20260630-usb_dyn_id_uaf-v1-3-160a02be5ac2@garyguo.net>
On Tue Jun 30, 2026 at 1:38 PM CEST, Gary Guo wrote:
> USB probe functions should not keep usb_device_id for longer than probe due
> to presence of dynamic ID removal. USB serial does not support ID removal,
> however in this case only driver_data is ever needed, there is no reason
> keeping the usb_device_id in the first place, so convert it as well.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
> ---
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] usb: usbtmc: don't keep usb_device_id
From: Danilo Krummrich @ 2026-06-30 21:51 UTC (permalink / raw)
To: Gary Guo
Cc: Greg Kroah-Hartman, Rafael J. Wysocki,
Toke Høiland-Jørgensen, Johan Hovold, linux-wireless,
linux-kernel, linux-usb, driver-core
In-Reply-To: <20260630-usb_dyn_id_uaf-v1-2-160a02be5ac2@garyguo.net>
On Tue Jun 30, 2026 at 1:38 PM CEST, Gary Guo wrote:
> usb_device_id is not guaranteed to live longer than probe due to presence
> of dynamic ID. This stored ID is unused so remove it.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/4] wifi: ath9k_htc: don't keep usb_device_id
From: Danilo Krummrich @ 2026-06-30 21:51 UTC (permalink / raw)
To: Gary Guo
Cc: Greg Kroah-Hartman, Rafael J. Wysocki,
Toke Høiland-Jørgensen, Johan Hovold, linux-wireless,
linux-kernel, linux-usb, driver-core
In-Reply-To: <20260630-usb_dyn_id_uaf-v1-1-160a02be5ac2@garyguo.net>
On Tue Jun 30, 2026 at 1:38 PM CEST, Gary Guo wrote:
> usb_device_id is not guaranteed to live longer than probe due to presence
> of dynamic ID. All information apart from driver_data can be easily
> retrieved from usb_device, so just store driver_data.
>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property
From: Rob Herring @ 2026-06-30 21:45 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Jens Axboe, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Srinivas Kandagatla,
Andrew Lunn, Heiner Kallweit, Russell King, Saravana Kannan,
Christian Marangi, linux-mmc, devicetree, linux-kernel,
linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, stable, Bartosz Golaszewski
In-Reply-To: <CAFEp6-163adAq8-H_pCzGnq+Fo4jpyKGs6Jv25j3fSpZg3COjQ@mail.gmail.com>
On Tue, Jun 30, 2026 at 2:59 PM Loic Poulain
<loic.poulain@oss.qualcomm.com> wrote:
>
> Hi Rob,
>
> On Tue, Jun 30, 2026 at 8:02 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Mon, Jun 29, 2026 at 10:55:20AM +0200, Loic Poulain wrote:
> > > Child nodes of a fixed-partitions node are not necessarily partition
> > > entries, for example an nvmem-layout node has no reg property. The
> > > current code passes a NULL reg pointer and uninitialized len to the
> > > length check, which can result in a kernel panic or silent failure to
> > > register any partitions.
> >
> > That does not sound right to me. A fixed-partitions node should only be
> > defining partitions with address ranges. I would expect a partition node
> > could be nvmem-layout, but not the whole address range. If you wanted
> > the latter, then just do:
> >
> > partitions {
> > ...
> > };
> >
> > nvmem-layout {
> > ...
> > };
>
> In our case, the nvmem-layout needs to be associated with a specific
> eMMC hardware partition, nvmem cells can be a simple sub-range within
> the global eMMC, each hardware partition (boot0, boot1, user...)
> having its own address spaces.
>
> That said, your point about not abusing fixed-partitions is valid. I
> initially dropped the compatible = "fixed-partitions" from the
> partitions-boot1 node when it only carries an nvmem-layout and no
> actual partition entries, making it a plain named container node. But
> it's a bit fragile if we want to support both nvmem-layout and
> fixed-partitions.
>
> Regarding your expectation of a partition node being a nvmem-layout,
> do you mean that the nvmem-layout should live under a fixed-partitions
> node? Something along these lines:
>
> partitions-boot1 {
> compatible = "fixed-partitions";
> #address-cells = <1>;
> #size-cells = <1>;
>
> nvmem@4400 {
partition@4400
> reg = <0x4400 0x1000>;
>
> nvmem-layout {
> compatible = "fixed-layout";
> #address-cells = <1>;
> #size-cells = <1>;
>
> wifi_mac_addr: mac-addr@0 {
> compatible = "mac-base";
> reg = <0x0 0x6>;
> #nvmem-cell-cells = <1>;
> };
> [...]
Either this or replacing "fixed-partitions" with "fixed-layout" if you
want to make the whole boot1 partition nvmem-layout looks like the
right way to me.
> That makes some sense, this would require extra work for the
> emmc/block layer to also associate fwnodes with logical partitions,
> not just the whole disk/hw (hw part), Is that the direction you'd like
> us to go?
Yes.
> Also, Note that regardless of which approach we settle on, this
> specific fix/patch remains necessary to validate the partition node
> and prevent NULL-deref.
Fair enough, though the reasoning for it would be different and
perhaps should give a warning.
Rob
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: correct monitor destination ring size
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Aaradhana Sahu; +Cc: linux-wireless
In-Reply-To: <20260616062342.4079796-1-aaradhana.sahu@oss.qualcomm.com>
On Tue, 16 Jun 2026 11:53:42 +0530, Aaradhana Sahu wrote:
> The default memory profile configures rxdma_monitor_dst_ring_size as 8092,
> which is a typo. The intended value is 8192, consistent with all other ring
> sizes in the table being powers of two.
>
> Correct the monitor destination ring size to 8192.
>
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: correct monitor destination ring size
commit: 913998f903fb1432c0046c33003db38a9e8bedb1
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: change MAC buffer ring size to 4096
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Yingying Tang; +Cc: linux-wireless, yintang
In-Reply-To: <20260610031358.2043716-1-yingying.tang@oss.qualcomm.com>
On Tue, 09 Jun 2026 20:13:58 -0700, Yingying Tang wrote:
> For WCN7850, MAC buffer ring size is updated to 2048 in
> 955df16f2a4c3 ("wifi: ath12k: change MAC buffer ring size to 2048")
> to increase peak throughput.
>
> But during the RX process, a phenomenon can still be observed where
> the throughput drops by about 30% from its peak value and then recovers,
> and this behavior repeats during RX.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: change MAC buffer ring size to 4096
commit: 58aeb412495ada7fe5495c7805504d7cf1d45453
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/2] wifi: ath12k: correct monitor-mode RX metadata handling
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Sushant Butta; +Cc: linux-wireless
In-Reply-To: <20260609064856.547032-1-sushant.butta@oss.qualcomm.com>
On Tue, 09 Jun 2026 12:18:54 +0530, Sushant Butta wrote:
> This series fixes monitor-mode meta data handling in ath12k and trims dead code:
>
> Monitor mode delivers raw 802.11 frames should not set RX_FLAG_8023 flag,
> and populate peer/link metadata in ieee80211_rx_status for monitor MSDUs.
>
> Sushant Butta (2):
> wifi: ath12k: Skip setting RX_FLAG_8023 for Ethernet-II (DIX) frames
> in monitor mode
> wifi: ath12k: Skip peer link info update in rx_status for monitor
> MSDUs
>
> [...]
Applied, thanks!
[1/2] wifi: ath12k: Skip setting RX_FLAG_8023 for Ethernet-II (DIX) frames in monitor mode
commit: 5a2b5d6a5a4a19b86d1c0698a3eb3d21f0b06401
[2/2] wifi: ath12k: Skip peer link info update in rx_status for monitor MSDUs
commit: 56f8f12c1a3c5312de0d7312b229d7bca03dbb81
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v2 0/3] wifi: ath12k: Improve dp stats
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Sreeramya Soratkal; +Cc: linux-wireless
In-Reply-To: <20260626085253.3927269-1-sreeramya.soratkal@oss.qualcomm.com>
On Fri, 26 Jun 2026 14:22:50 +0530, Sreeramya Soratkal wrote:
> This short series improves the device_dp_stats debugfs interface in
> ath12k to produce more useful and accurate diagnostic output in MLO
> configurations.
>
> Patch 1 fixes a latent correctness issue where the REO Rx and WBM
> release error tables were unconditionally printed for
> ATH12K_MAX_DEVICES columns showing zero-filled entries for device
> slots that have no hardware. Replacing the compile-time constant
> with the runtime device count keeps the output compact and correct.
>
> [...]
Applied, thanks!
[1/3] wifi: ath12k: Use runtime device count in dp stats display
commit: 34620d1890cc1fcf87a95219d6781d7f7b9d8cbd
[2/3] wifi: ath12k: Add timestamp to dp stats display
commit: 6cc84fce7b999b0c6c8aaccdfa8669f0a55e8586
[3/3] wifi: ath12k: Show per-radio center freq in dp stats
commit: b1d8d626e206a757b745af2adcbc7127ec593a20
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: Advertise multicast Ethernet encapsulation offload support
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Tamizh Chelvam Raja; +Cc: linux-wireless
In-Reply-To: <20260623100501.2100119-1-tamizh.raja@oss.qualcomm.com>
On Tue, 23 Jun 2026 15:35:01 +0530, Tamizh Chelvam Raja wrote:
> Advertise IEEE80211_OFFLOAD_ENCAP_MCAST to inform mac80211 that
> multicast frame encapsulation is handled in hardware. This allows
> mac80211 to pass Ethernet-formatted multicast frames directly to
> the driver.
>
> In ath12k_wifi7_mac_op_tx(), refine the logic that selects the MLO
> multicast replication path. Add a sta pointer check so that only unicast
> Hardware-encap frames use the direct transmit path, while multicast
> Hardware-encap frames fall through to the MLO replication loop and are
> transmitted on each active link.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: Advertise multicast Ethernet encapsulation offload support
commit: e47d6c9bb4165721f61356f5fccae8f7dd78876b
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v2] wifi: ath12k: advertise ieee_link_id in vdev start MLO params
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Manish Dharanenthiran
Cc: linux-wireless, Hari Naraayana Desikan Kannan, Karthik M
In-Reply-To: <20260623-ieee_link_id-v2-1-8a89d71baf58@oss.qualcomm.com>
On Tue, 23 Jun 2026 11:16:21 +0530, Manish Dharanenthiran wrote:
> Firmware builds the AP MLD partner profile from the hw_link_id passed in
> the vdev start parameters. However, hw_link_id is not always the same as
> the logical per-MLD ieee_link_id, since ieee_link_id is assigned per MLD
> and not per pdev.
>
> This matters in mixed MLO and SLO setups. For example:
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: advertise ieee_link_id in vdev start MLO params
commit: 784f7dabf5d3bce23c69c48a0441ff2b1536f069
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: reset REOQ LUT addresses before firmware stop
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Aishwarya R; +Cc: linux-wireless, P Praneesh
In-Reply-To: <20260619120751.363340-1-aishwarya.r@oss.qualcomm.com>
On Fri, 19 Jun 2026 17:37:51 +0530, Aishwarya R wrote:
> During module removal, REOQ LUT cleanup writes 0 to the REOQ/ML-REOQ
> LUT address registers. That cleanup runs from ath12k_core_stop(),
> after ath12k_qmi_firmware_stop() has already stopped the
> firmware (mode OFF), so the register writes can hit an invalid target
> access.
>
> Move the REOQ LUT register reset before ath12k_qmi_firmware_stop(),
> so the registers are cleared before stopping the firmware,
> while register access is still valid.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: reset REOQ LUT addresses before firmware stop
commit: fe2b006c15f6b1f81524b4c1af8013bc32fa0abc
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: expand UserPD ID mask to support up to 8 PDs
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Aaradhana Sahu; +Cc: linux-wireless
In-Reply-To: <20260604031551.4178754-1-aaradhana.sahu@oss.qualcomm.com>
On Thu, 04 Jun 2026 08:45:51 +0530, Aaradhana Sahu wrote:
> Currently ATH12K_USERPD_ID_MASK uses GENMASK(9, 8), which defines a
> 2-bit field and limits supported UserPD IDs to values 0-3.
>
> Future IPQ5332 multi-PD platform variants support more than three
> UserPDs. Expand ATH12K_USERPD_ID_MASK to GENMASK(10, 8), increasing
> the field width to 3 bits and allowing UserPD IDs from 0-7.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: expand UserPD ID mask to support up to 8 PDs
commit: c2d60ab8e3827de2cbf951491e5de339e4bb2eb9
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next 0/5] wifi: ath12k: fix dp_mon RX parsing for 32-bit TLV
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: jjohnson, Miaoqing Pan; +Cc: ath12k, linux-wireless, linux-kernel
In-Reply-To: <20260509025819.1641630-1-miaoqing.pan@oss.qualcomm.com>
On Sat, 09 May 2026 10:58:14 +0800, Miaoqing Pan wrote:
> This series fixes RX monitor status parsing issues on platforms using
> 32-bit TLV headers (e.g. QCC2072), and tightens TLV decoding robustness
> in ath12k datapath monitor handling.
>
>
Applied, thanks!
[1/5] wifi: ath12k: fix TLV32 length mask
commit: d762bbc08ca70a1985c9f9420c4bf67e0ba0e9be
[2/5] wifi: ath12k: refactor HAL TLV32/64 decode helpers
commit: e264a3dbe866870ed21ef83c67ad956a45391859
[3/5] wifi: ath12k: add HAL ops for monitor TLV header decode and alignment
commit: 9d1d61121b05c0a854e6da227e37b99b3740dae9
[4/5] wifi: ath12k: add dp_mon support 32-bit TLV headers
commit: 4c09bbf0c1e11bae19a0643bd9824d4f05d9c281
[5/5] wifi: ath12k: tighten RX monitor TLV bounds check
commit: fffa54aeaeb2e9ac923254b39e89bf07799615aa
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next v3] wifi: ath12k: avoid setting 320MHz support on non 6GHz band
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Nicolas Escande; +Cc: linux-wireless
In-Reply-To: <20260623151613.72113-1-nico.escande@gmail.com>
On Tue, 23 Jun 2026 17:16:13 +0200, Nicolas Escande wrote:
> On a split phy qcn9274 (2.4GHz + 5GHz low), "iw phy" reports 320MHz
> related features on the 5GHz band while it should not:
>
> Wiphy phy1
> [...]
> Band 2:
> [...]
> EHT Iftypes: managed
> [...]
> EHT PHY Capabilities: (0xe2ffdbe018778000):
> 320MHz in 6GHz Supported
> [...]
> Beamformee SS (320MHz): 7
> [...]
> Number Of Sounding Dimensions (320MHz): 3
> [...]
> EHT MCS/NSS: (0x22222222222222222200000000):
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: avoid setting 320MHz support on non 6GHz band
commit: eaf478b3ea68e1b5df659acd24c4df5850e12325
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: remove unused QMI definitions
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: ath12k, Aaradhana Sahu; +Cc: linux-wireless
In-Reply-To: <20260623035104.3765404-1-aaradhana.sahu@oss.qualcomm.com>
On Tue, 23 Jun 2026 09:21:04 +0530, Aaradhana Sahu wrote:
> The driver contains several unused QMI definitions such as response
> length macros, message IDs, firmware segment length definitions, and
> CALDB address size definitions.
>
> Remove these unused definitions as they are not referenced anywhere in
> the driver.
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: remove unused QMI definitions
commit: 007b638ed7242daeea7c1078e8f732d127c790f3
Best regards,
--
Jeff Johnson <jeff.johnson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH ath-next] wifi: ath12k: use %u for unsigned variables in QMI debug logs
From: Jeff Johnson @ 2026-06-30 21:26 UTC (permalink / raw)
To: Jeff Johnson, Raj Kumar Bhagat; +Cc: linux-wireless, ath12k, linux-kernel
In-Reply-To: <20260623-qmi-debug-log-v1-1-79471aa8b898@oss.qualcomm.com>
On Tue, 23 Jun 2026 09:34:17 +0530, Raj Kumar Bhagat wrote:
> Replace incorrect %d format specifiers with %u for unsigned variables
> in qmi.c debug messages. Also add missing trailing '\n' in log messages
> to ensure proper termination. No functional change intended.
>
> Tested-on: Compile tested only.
>
>
> [...]
Applied, thanks!
[1/1] wifi: ath12k: use %u for unsigned variables in QMI debug logs
commit: 26d529b99861707ed0a4c626184b9399bedca808
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