Re: [PATCH v2] iio: ssp: Serialize watchdog timer state changes
From: Andriy Shevchenko
Date: Sun Oct 04 2026 - 04:40:42 EST
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