On Thu, Jan 7, 2016 at 11:15 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > 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? 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 -- 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
