The QCA6174 experiences random cases of a key failing to be disabled. The timeout for this currently is 3 seconds. This can happen on roaming when removing the old key during the transition to the new BSS. Though the roam will generally succeed (except with some AP vendors, explained below) it means that it is delayed by 3 seconds until the timeout expires. Certain AP vendors appear to have issues with this delay and either ignore the subsequent reassociation, or reject it. This results in a disconnect. Since key removal is a non-fatal failure it feels somewhat safe to reduce this timeout down in order to both reduce the potential delay and play nice with APs that aren't able to handle the delay between authentication and association. Signed-off-by: James Prestwood <prestwoj@xxxxxxxxx> --- drivers/net/wireless/ath/ath10k/mac.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index ec8d5b29bc72..fd20107abd0f 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -301,6 +301,7 @@ static int ath10k_install_key(struct ath10k_vif *arvif, struct ath10k *ar = arvif->ar; int ret; unsigned long time_left; + unsigned long timeout = (cmd == DISABLE_KEY) ? 1 : 3; lockdep_assert_held(&ar->conf_mutex); @@ -313,7 +314,8 @@ static int ath10k_install_key(struct ath10k_vif *arvif, if (ret) return ret; - time_left = wait_for_completion_timeout(&ar->install_key_done, 3 * HZ); + time_left = wait_for_completion_timeout(&ar->install_key_done, + timeout * HZ); if (time_left == 0) return -ETIMEDOUT; -- 2.34.1
