On Thu, 2015-12-31 at 10:41 +0200, Emmanuel Grumbach wrote: > > 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? [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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
