On 10/21/22 10:51, Martin Blumenstingl wrote:
Hi Guenter,
On Fri, Oct 21, 2022 at 7:11 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
[...]
@@ -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.
Thanks for spotting this - this is indeed a potential issue.
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.
Thanks for noticing. I had missed that one. Yes, please.
Thanks,
Guenter
