+ if (!ext_native && key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) { + key->flags |= KEY_FLAG_RX_SW_CRYPTO; + /* Activate Rx crypto offload after max 10s when idle */ + ieee80211_queue_delayed_work(&local->hw, &sta->ext_key_compat_wk, + round_jiffies_relative(HZ * 10)); + }Is there much point in this?+ if (unlikely(rx->key->flags & KEY_FLAG_RX_SW_CRYPTO)) { + rx->key->flags &= ~KEY_FLAG_RX_SW_CRYPTO; + cancel_delayed_work(&rx->sta->ext_key_compat_wk); + ieee80211_queue_delayed_work(&rx->local->hw, + &rx->sta->ext_key_compat_wk, 0); + }We'll almost certainly do it from here, so never exercise the other path?
This is mostly to have a definite time we know the new key is used also for RX. In probably 99.9% of all cases it will be triggered from the Rx path. Some special purpose devices may not send any packets for a long time and trigger the fallback, as (wrong) firewall rules. (I've e.g. tested it by dropping all outgoing packets on the remote sta.)
The idea was to be sure that a rekey intervall >10s prevents activating Rx crypt when rekeying the next key. Which now sounds kind of thin...
So I'll remove the 10s fallback.
