Re: [PATCH 2/2] hwmon: (sht4x) Fix return value from heater_enable_store()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unit mismatch between jiffies and milliseconds in sht4x_read_values timeout calculation
--

--- Patch [2]: [PATCH 2/2] hwmon: (sht4x) Fix return value from heater_enable_store() ---
commit ffda8f58b43906bc1ea2253c2bf9b7981f601ded
Author: Guenter Roeck <[email protected]>

hwmon: (sht4x) Fix return value from heater_enable_store()

The return value in heater_enable_store() causes an unexpected write
failure in user-space because it returns 0 instead of count. This signals
to VFS that no bytes were processed, leading to a busy retry loop.
Returning count fixes the problem.

> diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c
> index 7a0dc2ed723d8..a97dda9e92dc5 100644
> --- a/drivers/hwmon/sht4x.c
> +++ b/drivers/hwmon/sht4x.c
> @@ -288,7 +288,7 @@ static ssize_t heater_enable_store(struct device *dev,
>  
>  	data->heating_complete = jiffies + msecs_to_jiffies(heating_time_bound);

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing how
data->heating_complete is used, I noticed a unit mismatch in
sht4x_read_values().

In sht4x_read_values(), the code calculates the timeout like this:

	if (data->data_pending &&
	    time_before(jiffies, data->heating_complete + data->update_interval)) {
		data->data_pending = false;

Is data->update_interval expected to be in milliseconds here?

Since data->update_interval is added directly to data->heating_complete
(which is in jiffies) without using msecs_to_jiffies(), does this create a
distorted timeout window?

Could this cause the driver to return stale, artificially high temperature
data from the heater phase instead of taking a new ambient measurement?

>  	data->data_pending = true;
> -	return 0;
> +	return count;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2