Michal Kazior <michal.kazior@xxxxxxxxx> writes:
> In some cases hw recovery was taking an absurdly
> long time due to ath10k waiting for things that
> would never really complete.
>
> Instead of waiting for inevitable timeouts poke
> all completions and wakequeues and check if it's
> still worth waiting.
>
> Signed-off-by: Michal Kazior <michal.kazior@xxxxxxxxx>
[...]
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -685,6 +685,20 @@ static void ath10k_core_restart(struct work_struct *work)
> {
> struct ath10k *ar = container_of(work, struct ath10k, restart_work);
>
> + set_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
> + barrier();
Please document why the barrier is needed.
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -371,6 +371,11 @@ enum ath10k_dev_flags {
> /* Indicates that ath10k device is during CAC phase of DFS */
> ATH10K_CAC_RUNNING,
> ATH10K_FLAG_CORE_REGISTERED,
> +
> + /* Device has crashed and needs to restart. This indicates any pending
> + * waiters should immediately cancel instead of waiting for a time out.
> + */
> + ATH10K_FLAG_CRASH_FLUSH,
> };
Instead of a dev flag, should this actually be a new state to enum
ath10k_state? The reason I ask, I don't see how we would use this flag
with other states than with ATH10K_STATE_ON. Or is this needed because
of locking?
--
Kalle Valo
--
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
