[PATCH ath-next 5/8] wifi: ath10k: check the recovery deadline on its own timeline

[Jeff Johnson]

On 9/25/2026 5:26 AM, Kang Yang wrote:
> @@ -2536,8 +2537,11 @@ static void ath10k_core_recovery_check_work(struct work_struct *work)
>  	if (!atomic_read(&ar->pending_recovery))
>  		return;
>  
> -	if (!time_after(jiffies, recovery_start + ATH10K_RECOVERY_TIMEOUT_HZ))
> +	if (!time_after(jiffies, recovery_start + ATH10K_RECOVERY_TIMEOUT_HZ)) {
> +		queue_delayed_work(ar->workqueue_aux, &ar->recovery_check_work,
> +				   ATH10K_RECOVERY_TIMEOUT_HZ);
>  		return;
> +	}

Even with the help of two different review agents I don't understand the above
logic. Under what condition do you expect the above test to succeed? And
if/when it does succeed, why not delay for just the time left between jiffies
and recovery_start + ATH10K_RECOVERY_TIMEOUT_HZ?

Or as one agent writes:
The early re-arm path is only reachable on the first monitor firing, at the
strict time_after() boundary. Re-arming for a full
ATH10K_RECOVERY_TIMEOUT_HZ there creates timing-dependent recovery behavior:
a worker that runs exactly on the expiry jiffy delays failure accounting by
another 5s, while one that runs a jiffy later accounts immediately. Use
time_after_eq()/remove the branch, or rearm only for the remaining time/1
jiffy if early execution is genuinely possible.

/jeff