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. Best regards, Martin
