Re: [hwmon-next PATCH v5 4/4] hwmon: (adt7470) Add thermal zone sensor support

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [High] Registering the device as a thermal zone exposes the thermal subsy=
stem to severe latency stalls.
--

--- Patch [4]: [hwmon-next PATCH v5 4/4] hwmon: (adt7470) Add thermal zone =
sensor support ---
commit ee08dfc4b8ac9e072681b3ebf92b63eb473bf1a7
Author: Luiz Angelo Daros de Luca <[email protected]>

hwmon: (adt7470) Add thermal zone sensor support

This commit registers the ADT7470 temperature channels as thermal zone
sensors.

> diff --git a/drivers/hwmon/adt7470.c b/drivers/hwmon/adt7470.c
> index eeec3db0da88d..f652532f2f32e 100644
> --- a/drivers/hwmon/adt7470.c
> +++ b/drivers/hwmon/adt7470.c
> @@ -1396,6 +1396,8 @@ static const struct hwmon_ops adt7470_hwmon_ops =3D=
 {
>  };
> =20
>  static const struct hwmon_channel_info * const adt7470_info[] =3D {
> +	HWMON_CHANNEL_INFO(chip,
> +			   HWMON_C_REGISTER_TZ),

[Severity: High]
Will registering this device as a thermal zone cause severe latency stalls
for the thermal subsystem?

Looking at the background thread in the driver, it acquires the internal lo=
ck
before initiating a slow temperature read:

adt7470_update_thread() {
    ...
    mutex_lock(&data->lock);
    adt7470_read_temperatures(data);
    mutex_unlock(&data->lock);
    ...
}

Inside adt7470_read_temperatures(), the thread can sleep for up to 2 seconds
while still holding this lock:

adt7470_read_temperatures() {
    ...
    res =3D msleep_interruptible((data->num_temp_sensors >=3D 0 ?
                                data->num_temp_sensors * 200 :
                                TEMP_COLLECTION_TIME));
    ...
}

Since thermal zone registration causes the thermal core to automatically
and periodically poll the device, the thermal worker thread will attempt to
acquire data->lock. Because the lock is held for up to 2 seconds by the
background kthread, the thermal polling thread will be frequently delayed.

Additionally, while the thermal thread waits for data->lock, it also holds
the core hwdev->lock, which means any other userspace sysfs reads or writes
to this hwmon device will also stall.

Could this delay thermal mitigations for other devices on the system?

>  	HWMON_CHANNEL_INFO(temp,
>  			   HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX | HWMON_T_ALARM,
>  			   HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX | HWMON_T_ALARM,

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260730-adt7470_th=
[email protected]?part=3D4