Re: [PATCH v2] iio: ssp: Serialize watchdog timer state changes

[Andriy Shevchenko <andriy.shevchenko@intel.com>]

On Sun, Oct 04, 2026 at 01:39:27PM +0800, Runyu Xiao wrote:
> The SSP watchdog timer rearms itself from its callback, but the driver uses
> timer_delete_sync() when the last sensor is disabled and during suspend.
> Those operations do not prevent a concurrent enable or callback from
> rearming the timer after deletion. The final remove path also used
> timer_delete_sync(), which does not permanently prevent rearming before the
> device state is released.
> 
> Protect watchdog state and the enable reference count with wdt_lock. The
> timer callback rearms only while the timer is enabled, and synchronous
> deletion drains an in-flight callback. Use timer_shutdown_sync() for final
> removal so later rearm attempts are rejected permanently.
> 
> A refresh work item can call ssp_sync_available_sensors() and
> ssp_enable_sensor() during suspend. If the enable count is zero when
> suspend checks it, that work can otherwise start the watchdog after the
> suspend stop. Track the suspended state under wdt_lock. Sensor enables may
> update the count without restarting the timer. Stop the watchdog before
> sending the suspend command, and restart it only after resume succeeds or
> suspend fails.
> 
> Cancel watchdog work after releasing wdt_lock because reset work can wait
> for the threaded IRQ handler, which may synchronously wait for refresh work
> that enables sensors. Remove MFD children before destroying the locks;
> IIO child teardown can disable an active sensor.

General rule of thumb is to defer a new version until the discussion is settled
down in the previous round(s).

...

> struct ssp_data {

>  	struct spi_device *spi;
>  	const struct ssp_sensorhub_info *sensorhub_info;
>  	struct timer_list wdt_timer;
> +	struct mutex wdt_lock; /* protects watchdog timer state */
> +	bool wdt_enabled;
> +	bool wdt_suspended;
>  	struct work_struct work_wdt;
>  	struct delayed_work work_refresh;

Same Q here, can you reduce the gap by 4 bytes by rearranging the new members?

-- 
With Best Regards,
Andy Shevchenko