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

[Kang Yang]

On 10/16/2026 10:47 PM, Jeff Johnson wrote:
> 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.

Good catch...I will check this>
> /jeff