[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