| Message ID | 20211120204053.2299501-1-davidm@egauge.net (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/2] hwmon: (sht4x) Fix EREMOTEIO errors | expand |
On 11/20/21 12:40 PM, David Mosberger-Tang wrote: > Per datasheet, SHT4x may need up to 8.2ms for a "high repeatability" > measurement to complete. Attempting to read the result too early > triggers a NAK which then causes an EREMOTEIO error. > > This behavior has been confirmed with a logic analyzer while running > the I2C bus at only 40kHz. The low frequency precludes any > signal-integrity issues, which was also confirmed by the absence of > any CRC8 errors. In this configuration, a NAK occurred on any read > that followed the measurement command within less than 8.2ms. > > Signed-off-by: David Mosberger-Tang <davidm@egauge.net> You sent v2 after 5 minutes, and there is no change log. Please never do that, and always provide a change log. Guenter > --- > drivers/hwmon/sht4x.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c > index 09c2a0b06444..3415d7a0e0fc 100644 > --- a/drivers/hwmon/sht4x.c > +++ b/drivers/hwmon/sht4x.c > @@ -23,7 +23,7 @@ > /* > * I2C command delays (in microseconds) > */ > -#define SHT4X_MEAS_DELAY 1000 > +#define SHT4X_MEAS_DELAY_HPM 8200 /* see t_MEAS,h in datasheet */ > #define SHT4X_DELAY_EXTRA 10000 > > /* > @@ -90,7 +90,7 @@ static int sht4x_read_values(struct sht4x_data *data) > if (ret < 0) > goto unlock; > > - usleep_range(SHT4X_MEAS_DELAY, SHT4X_MEAS_DELAY + SHT4X_DELAY_EXTRA); > + usleep_range(SHT4X_MEAS_DELAY_HPM, SHT4X_MEAS_DELAY_HPM + SHT4X_DELAY_EXTRA); > > ret = i2c_master_recv(client, raw_data, SHT4X_RESPONSE_LENGTH); > if (ret != SHT4X_RESPONSE_LENGTH) { >
Repeat of previous patch but split into separate emails so the device-tree bits can be sent to the proper group of maintainers, as per Guenter's suggestion.
On Sat, Nov 20, 2021 at 09:28:53PM +0000, David Mosberger-Tang wrote: > Repeat of previous patch but split into separate emails so the > device-tree bits can be sent to the proper group of maintainers, as > per Guenter's suggestion. > Another rule: Never send a follow-up patch series as reply to a previous one; otherwise it might get lost. Also, if you send a single patch, there is not need for an introduction patch like this one. Thanks, Guenter
diff --git a/drivers/hwmon/sht4x.c b/drivers/hwmon/sht4x.c index 09c2a0b06444..3415d7a0e0fc 100644 --- a/drivers/hwmon/sht4x.c +++ b/drivers/hwmon/sht4x.c @@ -23,7 +23,7 @@ /* * I2C command delays (in microseconds) */ -#define SHT4X_MEAS_DELAY 1000 +#define SHT4X_MEAS_DELAY_HPM 8200 /* see t_MEAS,h in datasheet */ #define SHT4X_DELAY_EXTRA 10000 /* @@ -90,7 +90,7 @@ static int sht4x_read_values(struct sht4x_data *data) if (ret < 0) goto unlock; - usleep_range(SHT4X_MEAS_DELAY, SHT4X_MEAS_DELAY + SHT4X_DELAY_EXTRA); + usleep_range(SHT4X_MEAS_DELAY_HPM, SHT4X_MEAS_DELAY_HPM + SHT4X_DELAY_EXTRA); ret = i2c_master_recv(client, raw_data, SHT4X_RESPONSE_LENGTH); if (ret != SHT4X_RESPONSE_LENGTH) {
Per datasheet, SHT4x may need up to 8.2ms for a "high repeatability" measurement to complete. Attempting to read the result too early triggers a NAK which then causes an EREMOTEIO error. This behavior has been confirmed with a logic analyzer while running the I2C bus at only 40kHz. The low frequency precludes any signal-integrity issues, which was also confirmed by the absence of any CRC8 errors. In this configuration, a NAK occurred on any read that followed the measurement command within less than 8.2ms. Signed-off-by: David Mosberger-Tang <davidm@egauge.net> --- drivers/hwmon/sht4x.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)