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

[James Prestwood <prestwoj@gmail.com>]

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