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

[Kang Yang]

On 10/16/2026 9:07 AM, Jeff Johnson wrote:
> On 9/25/2026 5:26 AM, Kang Yang wrote:
>> @@ -8175,6 +8175,9 @@ static void ath10k_reconfig_complete(struct ieee80211_hw *hw,
>>   		atomic_set(&ar->fail_cont_count, 0);
>>   		atomic_set(&ar->pending_recovery, 0);
>>   
>> +		/* Stop the self-rearming monitor after recovery succeeds. */
>> +		cancel_delayed_work(&ar->recovery_check_work);
> 
> My review agent thinks this should be cancel_delayed_work_sync():
> Confirmed safe: ath10k_core_recovery_check_work() never acquires conf_mutex
> (neither does ath10k_core_enter_wedged()), so calling
> cancel_delayed_work_sync() from inside ath10k_reconfig_complete() which holds
> conf_mutex cannot deadlock.
> 
> The real problem with the non-_sync variant: if the work is currently running
> when cancel_delayed_work() is called (which returns 0 and does nothing), the
> work may call queue_delayed_work() to re-arm itself before checking
> pending_recovery == 0. That re-arm succeeds and the work fires again
> unnecessarily. cancel_delayed_work_sync() waits for the running instance to
> finish and prevents the spurious re-arm.


Agreed, will address this in next version.


> 
>> +
>>   		if (ar->hw_params.hw_restart_disconnect) {
>>   			list_for_each_entry(arvif, &ar->arvifs, list) {
>>   				if (arvif->is_up && arvif->vdev_type == WMI_VDEV_TYPE_STA)
>>
>