From: Guenter Roeck <linux@roeck-us.net>
To: Pascal Sachs <pascalsachs@gmail.com>
Cc: jdelvare@suse.com, corbet@lwn.net, pascal.sachs@sensirion.com,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
David Frey <david.frey@sensirion.com>
Subject: Re: [PATCH 1/1 v4] hwmon: add support for Sensirion SHT3x sensors
Date: Tue, 31 May 2016 10:26:26 -0700 [thread overview]
Message-ID: <20160531172626.GC14007@roeck-us.net> (raw)
In-Reply-To: <574D386B.8020805@gmail.com>
On Tue, May 31, 2016 at 09:08:27AM +0200, Pascal Sachs wrote:
> Hi Guenter
>
> I want to thank you again for the fast and detailed code review.
> I really appreciate it.
>
Sorry it took so long.
[ ... ]
> >>+static struct sht3x_data *sht3x_update_client(struct device *dev)
> >>+{
> >>+ struct sht3x_data *data = dev_get_drvdata(dev);
> >>+ struct i2c_client *client = data->client;
> >>+ u16 interval_ms = mode_to_update_interval[data->mode];
> >
> >If data->mode == 0, interval_ms == 0,
> >
> >>+ unsigned long interval_jiffies = msecs_to_jiffies(interval_ms);
> >
> >... interval_jiffies == 1,
> >
> >>+ unsigned char buf[SHT3X_RESPONSE_LENGTH];
> >>+ u16 val;
> >>+ int ret = 0;
> >>+
> >>+ mutex_lock(&data->data_lock);
> >>+ /* only update once per interval in periodic mode */
> >>+ if (time_after(jiffies, data->last_update + interval_jiffies)) {
> >
> >... and the command is executed every other timer tick. Is that
> >intentional ?
> Yes, this is how it should behave. In single shot mode the sensor measures
> values on demand, which means every time the sysfs interface is called, a
> measurement is triggered. In periodic mode however the measurement process
> is handled internally by the sensor and read out only makes sense if a new
> reading is available.
Please add the explanation as comment into the code.
[ ... ]
> >>+ commands = &limit_commands[index];
> >>+
> >>+ memcpy(position, commands->write_command, SHT3X_CMD_LENGTH);
> >>+ position += SHT3X_CMD_LENGTH;
> >>+ /*
> >>+ * ST = (T + 45) / 175 * 2^16
> >>+ * SRH = RH / 100 * 2^16
> >>+ * adapted for fixed point arithmetic and packed the same as
> >>+ * in limit_show()
> >>+ */
> >>+ raw = ((u32)(temperature + 45000) * 24543) >> (16 + 7);
> >>+ raw |= ((humidity * 42950) >> 16) & 0xfe00;
> >>+
> >>+ *((__be16 *)position) = cpu_to_be16(raw);
> >>+ position += SHT3X_WORD_LEN;
> >>+ *position = crc8(sht3x_crc8_table,
> >>+ position - SHT3X_WORD_LEN,
> >>+ SHT3X_WORD_LEN,
> >>+ SHT3X_CRC8_INIT);
> >>+
> >>+ mutex_lock(&data->data_lock);
> >>+ mutex_lock(&data->i2c_lock);
> >>+ ret = i2c_master_send(client, buffer, sizeof(buffer));
> >>+ mutex_unlock(&data->i2c_lock);
> >>+
> >>+ if (ret != sizeof(buffer))
> >>+ goto out;
> >>+
> >>+ data->temperature_limits[index] = temperature;
> >>+ data->humidity_limits[index] = humidity;
> >>+
> >>+out:
> >>+ mutex_unlock(&data->data_lock);
> >>+ if (ret != sizeof(buffer))
> >>+ return ret < 0 ? ret : -EIO;
> >>+
> >>+ return count;
> >
> >I would prefer something like
> >
> > if (ret != sizeof(buffer)) {
> > if (ret >= 0)
> > ret = -EIO;
> > goto out;
> > }
> >
> > ret = count;
> > data->temperature_limits[index] = temperature;
> > data->humidity_limits[index] = humidity;
> >out:
> > mutex_unlock(&data->data_lock);
> > return ret;
> >
> >which I think would be cleaner. See below though for locking issues.
> OK, wasn't sure if it is appropriate to handle error and valid return in the
> same variable
Done all over the place.
[ ... ]
> >
> >>+ mutex_lock(&data->i2c_lock);
> >>+ mutex_lock(&data->data_lock);
> >>+ /* abort periodic measure */
> >>+ ret = i2c_master_send(client, sht3x_cmd_break, SHT3X_CMD_LENGTH);
> >>+ if (ret != SHT3X_CMD_LENGTH)
> >>+ goto out;
> >>+ data->mode = 0;
> >>+
> >
> >Can you explain why you set data->mode = 0 here ?
> To do any changes to the configuration while in periodic mode we have to
> send a break command to the sensor, which then falls back to single shot
> mode (mode = 0). Therefore for consistency reasons we set the mode to
> the value it actually is at this point.
> If setting the new mode fails, we are still in single shot mode. Like this
> we
> ensure that the data->mode is always correct.
Ok; please add the explanation as comment into the code.
Thanks,
Guenter
prev parent reply other threads:[~2016-05-31 17:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-30 14:46 [PATCH 1/1 v4] hwmon: add support for Sensirion SHT3x sensors Pascal Sachs
2016-05-30 15:45 ` Guenter Roeck
2016-05-31 7:08 ` Pascal Sachs
2016-05-31 17:26 ` Guenter Roeck [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160531172626.GC14007@roeck-us.net \
--to=linux@roeck-us.net \
--cc=corbet@lwn.net \
--cc=david.frey@sensirion.com \
--cc=jdelvare@suse.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pascal.sachs@sensirion.com \
--cc=pascalsachs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.