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/[email protected]/
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
