On Thu, Jan 7, 2016 at 11:15 PM, Johannes Berg
[off-list ref] wrote:

On Thu, 2015-12-31 at 10:41 +0200, Emmanuel Grumbach wrote:

quoted

So essentially, this is a bug in the TX'ing side. Fixing it requires
to hit the performance which is not something people are willing to
do, when the bug is really in the spec.

I wonder if, for most devices, this is really true?

We could, after all, remove the key from hardware acceleration before
we replace it logically in software, avoiding the problem [1], like
this:

https://p.sipsolutions.net/a71aa559c27998c7.txt
(completely untested!)

This would slightly increase the window of time in which devices like
ath10k that require hardware crypto drop the frame entirely, but that
seems quite reasonable?

Yes - it looks reasonable. At least, worth being tested :)

[1] assuming the driver doesn't return from the set_key() method while
it still has frames that might have been decrypted with that key; which
again is clearly true for iwlwifi due to the combined data/firmware
command design, but maybe not fully guaranteed for ath9k