Hi Guenter,
On Fri, Oct 21, 2022 at 7:11 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
[...]
Thanks for spotting this - this is indeed a potential issue.@@ -368,17 +361,14 @@ static int jc42_write(struct device *dev, enum hwmon_sensor_types type,
}
data->config = (data->config & ~JC42_CFG_HYST_MASK) |
(hyst << JC42_CFG_HYST_SHIFT);
- ret = i2c_smbus_write_word_swapped(data->client,
- JC42_REG_CONFIG,
- data->config);
+ ret = regmap_write(data->regmap, JC42_REG_CONFIG,
+ data->config);
break;
This code sequence still requires a mutex since another thread could modify
the upper limit (and/or the hysteresis) while the hysteresis is in the process
of being written. Worst case there could be a mismatch between the value in
data->config and the value actually written into the chip. Granted, that is
unlikely to happen, but the race still exists.
Do you also want me to add locking for the data->config access (read)
in jc42_read()? Without a lock there in theory jc42_write() may have
already updated data->config with a new value while hardware still has
the old value. So in the end the read output may show a hysteresis
which was not programmed to the registers at that time.