[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:
> @@ -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.

> +
>  		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)
>