On Fri, Jan 12, 2018 at 08:06:00PM +0100, Emiliano Ingrassia wrote: > An sht3x sensor include limits register which contains temperature > and humidity limit values. After a reset, pre-defined values are loaded > into that register. During the probe function, the driver reads the > limits register. However, if the reads are made too early, for example > because the I2C bus frequency is high (e.g. 400 kHz), the loading could be > not completed and the sensor returns a NACK which causes the probe to fail. > A delay of at least 500 us before the first read solves this issue. > > Signed-off-by: Emiliano Ingrassia <ingrassia@xxxxxxxxxxxxxx> > --- > drivers/hwmon/sht3x.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/hwmon/sht3x.c b/drivers/hwmon/sht3x.c > index 6ea99cd6ae79..f2098443df2f 100644 > --- a/drivers/hwmon/sht3x.c > +++ b/drivers/hwmon/sht3x.c > @@ -732,6 +732,9 @@ static int sht3x_probe(struct i2c_client *client, > mutex_init(&data->i2c_lock); > mutex_init(&data->data_lock); > > + /* wait predefined limits loading complete before access */ The commit log explains the problem much better. This here is cryptic. Would you understand this if you would read it in an arbitrary driver ? Please consider something like: /* * If an attempt to read the limits is made too early after sending * the SHT3X_CMD_LENGTH command, the chip may respond with NACK. * This was observed on BeagleBone Black on an i2c bus clocked * at 400 kHz. The delay was chosen empirically. */ Answering your question, no, I don't have any personal experience with this chip. My comments are generic. Guenter > + usleep_range(500, 600); > + > ret = limits_update(data); > if (ret) > return ret; > -- > 2.15.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
