[RFC PATCH 0/2] ath10k wifi fixes

[RFC PATCH 0/2] ath10k wifi fixes

[Richard Acayan]

These are WiFi fixes that seem to be helpful on SDM670. There is no
ath10k support for SDM670, but some similar SoCs also need these fixes.
This is RFC because there could be better solutions.

On SDM670 with patches, the MPDU has 32 MSDUs when the last one isn't
the last in the A-MSDU.

Richard Acayan (2):
  wifi: ath10k: make in-order rx amsdu buffers persistent
  wifi: ath10k: only wait for response to SET_KEY

 drivers/net/wireless/ath/ath10k/htt.h    |  4 +++
 drivers/net/wireless/ath/ath10k/htt_rx.c | 41 ++++++++++++++++++------
 drivers/net/wireless/ath/ath10k/mac.c    |  8 +++--
 3 files changed, 41 insertions(+), 12 deletions(-)

-- 
2.53.0

[RFC PATCH 1/2] wifi: ath10k: make in-order rx amsdu buffers persistent

[Richard Acayan]

The WCN3990 might split MSDUs among multiple "in-order" indications. The
driver needs information from previous indications to handle MPDUs that
are not started by the same indications that complete them. Move the
list that tracks unprocessed MSDUs to the driver state so the driver can
handle MPDUs that are split in this way and be less confused.

Fixes: c545070e404b ("ath10k: implement rx reorder support")
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
 drivers/net/wireless/ath/ath10k/htt.h    |  4 +++
 drivers/net/wireless/ath/ath10k/htt_rx.c | 41 ++++++++++++++++++------
 2 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 603f6de62b0a..ec897175c933 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1929,6 +1929,10 @@ struct ath10k_htt {
 	bool bundle_tx;
 	struct sk_buff_head tx_req_head;
 	struct sk_buff_head tx_complete_head;
+
+	u8 rx_in_ord_split_tid;
+	u16 rx_in_ord_split_peer_id;
+	struct sk_buff_head rx_in_ord_split;
 };
 
 struct ath10k_htt_tx_ops {
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index d7e429041065..b27271c56d07 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -297,6 +297,8 @@ void ath10k_htt_rx_free(struct ath10k_htt *htt)
 	skb_queue_purge(&htt->rx_in_ord_compl_q);
 	skb_queue_purge(&htt->tx_fetch_ind_q);
 
+	skb_queue_purge(&htt->rx_in_ord_split);
+
 	spin_lock_bh(&htt->rx_ring.lock);
 	ath10k_htt_rx_ring_free(htt);
 	spin_unlock_bh(&htt->rx_ring.lock);
@@ -846,6 +848,8 @@ int ath10k_htt_rx_alloc(struct ath10k_htt *htt)
 	skb_queue_head_init(&htt->tx_fetch_ind_q);
 	atomic_set(&htt->num_mpdus_ready, 0);
 
+	skb_queue_head_init(&htt->rx_in_ord_split);
+
 	ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt rx ring size %d fill_level %d\n",
 		   htt->rx_ring.size, htt->rx_ring.fill_level);
 	return 0;
@@ -3264,7 +3268,6 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 	struct ath10k_htt *htt = &ar->htt;
 	struct htt_resp *resp = (void *)skb->data;
 	struct ieee80211_rx_status *status = &htt->rx_status;
-	struct sk_buff_head list;
 	struct sk_buff_head amsdu;
 	u16 peer_id;
 	u16 msdu_count;
@@ -3299,16 +3302,32 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 		return -EINVAL;
 	}
 
+	if (!skb_queue_empty(&htt->rx_in_ord_split)) {
+		/* It might still be possible to handle this case if there is
+		 * only one peer that splits at each given moment. We are
+		 * bailing out because we should have a test case for this
+		 * before trying to fix it.
+		 */
+		if (tid != htt->rx_in_ord_split_tid
+		 || peer_id != htt->rx_in_ord_split_peer_id
+		 || offload) {
+			ath10k_warn(ar, "split amsdu did not resume immediately\n");
+			htt->rx_confused = true;
+			return -EIO;
+		}
+	}
+
 	/* The event can deliver more than 1 A-MSDU. Each A-MSDU is later
 	 * extracted and processed.
+	 *
+	 * It can also continue a previous A-MSDU.
 	 */
-	__skb_queue_head_init(&list);
 	if (ar->hw_params.target_64bit)
 		ret = ath10k_htt_rx_pop_paddr64_list(htt, &resp->rx_in_ord_ind,
-						     &list);
+						     &htt->rx_in_ord_split);
 	else
 		ret = ath10k_htt_rx_pop_paddr32_list(htt, &resp->rx_in_ord_ind,
-						     &list);
+						     &htt->rx_in_ord_split);
 
 	if (ret < 0) {
 		ath10k_warn(ar, "failed to pop paddr list: %d\n", ret);
@@ -3320,11 +3339,12 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 	 * separately.
 	 */
 	if (offload)
-		ath10k_htt_rx_h_rx_offload(ar, &list);
+		ath10k_htt_rx_h_rx_offload(ar, &htt->rx_in_ord_split);
 
-	while (!skb_queue_empty(&list)) {
+	while (!skb_queue_empty(&htt->rx_in_ord_split)) {
 		__skb_queue_head_init(&amsdu);
-		ret = ath10k_htt_rx_extract_amsdu(&ar->hw_params, &list, &amsdu);
+		ret = ath10k_htt_rx_extract_amsdu(&ar->hw_params,
+						  &htt->rx_in_ord_split, &amsdu);
 		switch (ret) {
 		case 0:
 			/* Note: The in-order indication may report interleaved
@@ -3340,12 +3360,15 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
 			ath10k_htt_rx_h_enqueue(ar, &amsdu, status);
 			break;
 		case -EAGAIN:
-			fallthrough;
+			htt->rx_in_ord_split_tid = tid;
+			htt->rx_in_ord_split_peer_id = peer_id;
+
+			return -EIO;
 		default:
 			/* Should not happen. */
 			ath10k_warn(ar, "failed to extract amsdu: %d\n", ret);
 			htt->rx_confused = true;
-			__skb_queue_purge(&list);
+			__skb_queue_purge(&htt->rx_in_ord_split);
 			return -EIO;
 		}
 	}
-- 
2.53.0

[RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[Richard Acayan]

When sending DELETE_KEY, the driver times out waiting for a response
that doesn't come. Only wait for a response when sending SET_KEY.

Sample dmesg:

	[  117.285854] wlan0: deauthenticating from XX:XX:XX:XX:XX:XX by local choice (Reason: 3=DEAUTH_LEAVING)
	[  120.302934] ath10k_snoc 18800000.wifi: failed to install key for vdev 0 peer XX:XX:XX:XX:XX:XX: -110
	[  120.302996] wlan0: failed to remove key (0, XX:XX:XX:XX:XX:XX) from hardware (-110)

Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index da6f7957a0ae..73aa93043f8a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -324,9 +324,11 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
 	if (ret)
 		return ret;
 
-	time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
-	if (time_left == 0)
-		return -ETIMEDOUT;
+	if (cmd != DISABLE_KEY) {
+		time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
+		if (time_left == 0)
+			return -ETIMEDOUT;
+	}
 
 	return 0;
 }
-- 
2.53.0

Re: [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[James Prestwood]

On 2/9/26 6:12 PM, Richard Acayan wrote:
> When sending DELETE_KEY, the driver times out waiting for a response
> that doesn't come. Only wait for a response when sending SET_KEY.

We've run into the exact same thing on the QCA6174 and have been 
carrying an identical patch to this for at least a year.

https://lore.kernel.org/linux-wireless/b2838a23-ea30-4dee-b513-f5471d486af2@gmail.com/

>
> Sample dmesg:
>
> 	[  117.285854] wlan0: deauthenticating from XX:XX:XX:XX:XX:XX by local choice (Reason: 3=DEAUTH_LEAVING)
> 	[  120.302934] ath10k_snoc 18800000.wifi: failed to install key for vdev 0 peer XX:XX:XX:XX:XX:XX: -110
> 	[  120.302996] wlan0: failed to remove key (0, XX:XX:XX:XX:XX:XX) from hardware (-110)
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
>   drivers/net/wireless/ath/ath10k/mac.c | 8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index da6f7957a0ae..73aa93043f8a 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -324,9 +324,11 @@ static int ath10k_install_key(struct ath10k_vif *arvif,
>   	if (ret)
>   		return ret;
>   
> -	time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
> -	if (time_left == 0)
> -		return -ETIMEDOUT;
> +	if (cmd != DISABLE_KEY) {
> +		time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ);
> +		if (time_left == 0)
> +			return -ETIMEDOUT;
> +	}
>   
>   	return 0;
>   }

Re: [RFC PATCH 1/2] wifi: ath10k: make in-order rx amsdu buffers persistent

[Jeff Johnson]

On 2/9/2026 6:12 PM, Richard Acayan wrote:

some nits from my tooling...

> @@ -3299,16 +3302,32 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb)
>  		return -EINVAL;
>  	}
>  
> +	if (!skb_queue_empty(&htt->rx_in_ord_split)) {
> +		/* It might still be possible to handle this case if there is

note that networking code no longer has a special block comment style, so all
new block comments should use the standard style which has the opening "/*" on
a line by itself.

> +		 * only one peer that splits at each given moment. We are
> +		 * bailing out because we should have a test case for this
> +		 * before trying to fix it.
> +		 */
> +		if (tid != htt->rx_in_ord_split_tid
> +		 || peer_id != htt->rx_in_ord_split_peer_id
> +		 || offload) {

checkpatch complains:
LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line

> +			ath10k_warn(ar, "split amsdu did not resume immediately\n");
> +			htt->rx_confused = true;
> +			return -EIO;
> +		}
> +	}
> +
Just wanted to get those out of the way before I look at the real content of
the patch.

/jeff

Re: [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[Jeff Johnson]

On 2/11/2026 6:11 PM, James Prestwood wrote:
> On 2/9/26 6:12 PM, Richard Acayan wrote:
>> When sending DELETE_KEY, the driver times out waiting for a response
>> that doesn't come. Only wait for a response when sending SET_KEY.
> 
> We've run into the exact same thing on the QCA6174 and have been 
> carrying an identical patch to this for at least a year.
> 
> https://lore.kernel.org/linux-wireless/b2838a23-ea30-4dee-b513-f5471d486af2@gmail.com/

Baochen,
Were we ever able to reproduce this?
Do we normally always get a response to DELETE_KEY but in some instances it
comes very late (or not at all)?
If we remove the wait, is there any concern that a late arriving DELETE_KEY
response might be processed as a response to a subsequent SET_KEY command?

/jeff

Re: [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[Felix Kaechele]

I also had some hopes that this patch would fix the issue for me on 
QCA9739 SDIO, but even with this patch I am still getting the warnings 
in dmesg.

Regards,
Felix

Re: [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[James Prestwood]

Hi Jeff/Baochen,

On 2/12/26 9:56 AM, Jeff Johnson wrote:
> On 2/11/2026 6:11 PM, James Prestwood wrote:
>> On 2/9/26 6:12 PM, Richard Acayan wrote:
>>> When sending DELETE_KEY, the driver times out waiting for a response
>>> that doesn't come. Only wait for a response when sending SET_KEY.
>> We've run into the exact same thing on the QCA6174 and have been
>> carrying an identical patch to this for at least a year.
>>
>> https://lore.kernel.org/linux-wireless/b2838a23-ea30-4dee-b513-f5471d486af2@gmail.com/
> Baochen,
> Were we ever able to reproduce this?
> Do we normally always get a response to DELETE_KEY but in some instances it
> comes very late (or not at all)?
> If we remove the wait, is there any concern that a late arriving DELETE_KEY
> response might be processed as a response to a subsequent SET_KEY command?

For some added color, we only see this oddly with some vendors of APs, 
primarily "classic" Cisco Aeronet equipment (not Meraki).

Its still a mystery why certain AP vendors are able to trigger this 
given its deleting a key locally on the device. The major issue here is 
on roams when deleting the key from the prior BSS where we time out, 
thereby delaying the roam for 3 seconds. This then causes downstream 
effects like the reassociation timeout expiring on the AP which causes a 
disassociation. With some customers using Cisco its actually happens 
near 100% of the time, killing roaming entirely.

Thanks,

James

>
> /jeff

Re: [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[Felix Kaechele]

Hi,

On 2026-02-13 09:00, James Prestwood wrote:
> Hi Jeff/Baochen,
> 
> On 2/12/26 9:56 AM, Jeff Johnson wrote:
>> On 2/11/2026 6:11 PM, James Prestwood wrote:
>>> On 2/9/26 6:12 PM, Richard Acayan wrote:
>>>> When sending DELETE_KEY, the driver times out waiting for a response
>>>> that doesn't come. Only wait for a response when sending SET_KEY.
>>> We've run into the exact same thing on the QCA6174 and have been
>>> carrying an identical patch to this for at least a year.
>>>
>>> https://lore.kernel.org/linux-wireless/b2838a23-ea30-4dee-b513- 
>>> f5471d486af2@gmail.com/
>> Baochen,
>> Were we ever able to reproduce this?
>> Do we normally always get a response to DELETE_KEY but in some 
>> instances it
>> comes very late (or not at all)?
>> If we remove the wait, is there any concern that a late arriving 
>> DELETE_KEY
>> response might be processed as a response to a subsequent SET_KEY 
>> command?
> 
> For some added color, we only see this oddly with some vendors of APs, 
> primarily "classic" Cisco Aeronet equipment (not Meraki).

I use Ubiquiti nanoHD APs in my home network and have this issue with 
those. The device I am focusing on with this (Lenovo ThinkSmart View) 
originally came with Android and uses qcacld-2.0 there. I do see similar 
disconnects on group rekeying on Android as well and have reports from 
other users that WiFi does not consistently stay connected and on 
Android in some cases may even fail to reconnect at all.
With ath10k on near mainline Linux I have yet to see a full loss of 
connectivity.
To me this suggests that it's possibly a firmware issue.
I do have ath10k debug traces I can share, if this is helpful.

dmesg output:

qcom-msm8953 kernel: ath10k_sdio mmc1:0001:1: qca9379 hw1.0 sdio target 
0x05040000 chip_id 0x00000000 sub 0000:0000
qcom-msm8953 kernel: ath10k_sdio mmc1:0001:1: kconfig debug 1 debugfs 1 
tracing 1 dfs 0 testmode 0
qcom-msm8953 kernel: ath10k_sdio mmc1:0001:1: firmware ver 
WLAN.NPL.1.6-00163-QCANPLSWPZ-1 api 6 features wowlan,ignore-otp,mfp 
crc32 ac81ca26

Regards,
Felix

Re: [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[Baochen Qiang]

On 2/13/2026 1:56 AM, Jeff Johnson wrote:
> On 2/11/2026 6:11 PM, James Prestwood wrote:
>> On 2/9/26 6:12 PM, Richard Acayan wrote:
>>> When sending DELETE_KEY, the driver times out waiting for a response
>>> that doesn't come. Only wait for a response when sending SET_KEY.
>>
>> We've run into the exact same thing on the QCA6174 and have been 
>> carrying an identical patch to this for at least a year.
>>
>> https://lore.kernel.org/linux-wireless/b2838a23-ea30-4dee-b513-f5471d486af2@gmail.com/
> 
> Baochen,
> Were we ever able to reproduce this?

unfortunately no

> Do we normally always get a response to DELETE_KEY but in some instances it
> comes very late (or not at all)?

In my tests, I never hit this issue so seems can always get a response.

> If we remove the wait, is there any concern that a late arriving DELETE_KEY
> response might be processed as a response to a subsequent SET_KEY command?

I would suggest not to remove the wait, but instead reduce the timeout to like 1s, just
like the patch "[RFC 0/1] wifi: ath10k: improvement on key removal failure".

> 
> /jeff

Re: [RFC PATCH 2/2] wifi: ath10k: only wait for response to SET_KEY

[James Prestwood]

Hi,

On 2/25/26 6:59 PM, Baochen Qiang wrote:
>
> On 2/13/2026 1:56 AM, Jeff Johnson wrote:
>> On 2/11/2026 6:11 PM, James Prestwood wrote:
>>> On 2/9/26 6:12 PM, Richard Acayan wrote:
>>>> When sending DELETE_KEY, the driver times out waiting for a response
>>>> that doesn't come. Only wait for a response when sending SET_KEY.
>>> We've run into the exact same thing on the QCA6174 and have been
>>> carrying an identical patch to this for at least a year.
>>>
>>> https://lore.kernel.org/linux-wireless/b2838a23-ea30-4dee-b513-f5471d486af2@gmail.com/
>> Baochen,
>> Were we ever able to reproduce this?
> unfortunately no
>
>> Do we normally always get a response to DELETE_KEY but in some instances it
>> comes very late (or not at all)?
> In my tests, I never hit this issue so seems can always get a response.
>
>> If we remove the wait, is there any concern that a late arriving DELETE_KEY
>> response might be processed as a response to a subsequent SET_KEY command?
> I would suggest not to remove the wait, but instead reduce the timeout to like 1s, just
> like the patch "[RFC 0/1] wifi: ath10k: improvement on key removal failure".
>
Is there a specific reason to require a wait? I would be more ok if the 
way was sub-second, like 100ms or frankly even less (no idea what a 
"normal" amount of time is to delete a key). The issue is this effects 
roaming, and will delay roams by e.g. 1 second which is not ideal. I've 
also seen a 1 second wait cause issues with configurations that expect a 
very fast reassociation time. Even 1 second was causing a deauth.

I dropped this patch a long time ago and replaced it with a similar 
patch being discussed here. So far, no issues, though I realize this is 
a limited test with specific hardware.

Thanks,

James

>> /jeff