linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Roan van Dijk <roan@protonic.nl>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Tomasz Duszynski <tomasz.duszynski@octakon.com>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	David Jander <david@protonic.nl>
Subject: Re: [PATCH v1 3/3] drivers: iio: chemical: Add support for Sensirion SCD4x CO2 sensor
Date: Wed, 8 Sep 2021 18:08:26 +0100	[thread overview]
Message-ID: <20210908180826.7074161d@jic23-huawei> (raw)
In-Reply-To: <7b93a51a-3856-63a8-20fb-e2b7f341254a@protonic.nl>

On Tue, 7 Sep 2021 16:10:40 +0200
Roan van Dijk <roan@protonic.nl> wrote:

> On 05-09-2021 16:22, Jonathan Cameron wrote:
> > On Wed,  1 Sep 2021 12:59:11 +0200
> > Roan van Dijk <roan@protonic.nl> wrote:
> >  
> >> This is a driver for the SCD4x CO2 sensor from Sensirion. The sensor is
> >> able to measure CO2 concentration, temperature and relative humdity.
> >> The sensor uses a photoacoustic principle for measuring CO2 concentration.
> >> An I2C interface is supported by this driver in order to communicate with
> >> the sensor.
> >>
> >> Signed-off-by: Roan van Dijk <roan@protonic.nl>  
> > Hi Roan,
> >
> > Various comments inline.
> >
> > Thanks,
> >
> > Jonathan  
> Hi Jonathan,
> 
> Thank you for your feedback. Changes due to your
> comments will be added in the next patch.
> 
> However, I have some questions about some of the comments.
> I added my questions to your inline comments.
> Could you help me with these questions?
> 
> Thanks,
> 
> Roan
Replies follow,

Jonathan

> >> +static int scd4x_read_raw(struct iio_dev *indio_dev,
> >> +			struct iio_chan_spec const *chan, int *val,
> >> +			int *val2, long mask)
> >> +{
> >> +	struct scd4x_state *state = iio_priv(indio_dev);
> >> +	int ret;
> >> +	uint16_t tmp;
> >> +
> >> +	mutex_lock(&state->lock);
> >> +	switch (mask) {
> >> +	case IIO_CHAN_INFO_RAW:
> >> +	case IIO_CHAN_INFO_PROCESSED:
> >> +		ret = iio_device_claim_direct_mode(indio_dev);
> >> +		if (ret)
> >> +			break;
> >> +
> >> +		ret = scd4x_read_poll(state);  
> > Perhaps neater to wrap scd4x_read_poll() as scd4x_read_channel() that
> > returns the value for the requested channel.  That would make this
> > look like
> > 		
> > 		ret = scd4x_read_poll(state, chan->address);
> > 		iio_device_release_direct_mode();
> > 		if (ret)
> > 			return ret;
> >
> > 		*val = ret;
> > 		return IIO_VAL_INT;  
> The scd4x_read_poll() can return errors, like -ETIMEOUT. In that case
> we need to check here if ret has returned an error or data for the
> requested channel. Which could make the readability a bit harder.

This is pretty common for read type functions so readability impact
is not great.

> Besides the scd4x_read_poll() is also used in scd4x_trigger_handler()
> to read all channels at once instead of just one channel. So I think
> changing it to a request for one channel at a time, will not make it neater.

I'm suggesting a wrapper around that function not removing it.
What I would like to avoid is 'stashing' temporary variables inside
the state structure when there is not need.  An alternative would be to
pass in a buffer on the stack and put the value in that. 

> Or am I mistaken? I could still rename the function to
> scd4x_read_channels() if that makes more sense or do you have
> other suggestions?

The rename is a good idea anyway.

> >> +		if (ret) {
> >> +			iio_device_release_direct_mode(indio_dev);
> >> +			break;
> >> +		}
> >> +		*val = state->meas[chan->address];  
> > If you need to protect a local variable, use a local lock as well as
> > iio_device_release_direct_mode().  Today that function provides the
> > mutual exclusion you want but it isn't necessarily always going to do
> > so...
> >  
> >> +		iio_device_release_direct_mode(indio_dev);
> >> +		ret = IIO_VAL_INT;
> >> +		break;
> >> +	case IIO_CHAN_INFO_CALIBBIAS:
> >> +		ret = scd4x_read(state, CMD_GET_TEMP_OFFSET, &tmp, 3);
> >> +		if (ret)
> >> +			break;
> >> +		*val = 175000 * be16_to_cpu(tmp) / 65536;
> >> +		ret = IIO_VAL_INT;
> >> +		break;
> >> +	}
> >> +	mutex_unlock(&state->lock);
> >> +
> >> +	return ret;
> >> +}

...


> >> +
> >> +static ssize_t calibration_forced_value_store(struct device *dev,
> >> +					struct device_attribute *attr,
> >> +					const char *buf, size_t len)
> >> +{
> >> +	struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> >> +	struct scd4x_state *state = iio_priv(indio_dev);
> >> +	uint16_t val, arg;
> >> +	int ret;
> >> +
> >> +	ret = kstrtou16(buf, 0, &arg);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	if (arg < SCD4X_FRC_MIN_PPM || arg > SCD4X_FRC_MAX_PPM)
> >> +		return -EINVAL;
> >> +
> >> +	mutex_lock(&state->lock);
> >> +	ret = scd4x_write_and_fetch(state, CMD_FRC, arg, &val, 3);
> >> +	mutex_unlock(&state->lock);
> >> +
> >> +	if (val == 0xff) {
> >> +		dev_err(state->dev, "forced calibration has failed");
> >> +		return -EINVAL;
> >> +	}
> >> +
> >> +	return ret ?: len;
> >> +}
> >> +
> >> +static IIO_DEVICE_ATTR_RW(calibration_auto_enable, 0);
> >> +static IIO_DEVICE_ATTR_WO(calibration_forced_value, 0);
> >> +
> >> +static struct attribute *scd4x_attrs[] = {
> >> +	&iio_dev_attr_calibration_auto_enable.dev_attr.attr,  
> > Documentation in Documentation/ABI/sysfs-bus-iio-scd4x or similar needed.  
> What do you think is the best way to do this? To keep the ABI as simple
> as possible, I used the same attributes for scd4x as used by the scd30 
> driver.
> These attributes are already described in
> Documentation/ABI/sysfs-bus-iio-scd30. So should I make a new file for
> the scd4x with the same information or maybe rename the scd30 file
> to a shared file like Documentation/ABI/sysfs-bus-iio-scdxx?

Unfortunately the documentation build system doesn't support repeated
naming in multiple files.  So you need to pull this into a common file.
Given it isn't c02 sensor specific, move it from the scd30 to the
main sysfs-bus-iio file.

> >> +	&iio_dev_attr_calibration_forced_value.dev_attr.attr,
> >> +	NULL
> >> +};
> >> +

...

      parent reply	other threads:[~2021-09-08 17:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 10:59 [PATCH v1 0/3] iio: chemical: Add support for Sensirion SCD4x CO2 sensor Roan van Dijk
2021-09-01 10:59 ` [PATCH v1 1/3] dt-bindings: iio: chemical: sensirion,scd4x: Add yaml description Roan van Dijk
2021-09-03 19:51   ` Rob Herring
2021-09-07 13:13     ` Roan van Dijk
2021-09-01 10:59 ` [PATCH v1 2/3] MAINTAINERS: Add myself as maintainer of the scd4x driver Roan van Dijk
2021-09-01 10:59 ` [PATCH v1 3/3] drivers: iio: chemical: Add support for Sensirion SCD4x CO2 sensor Roan van Dijk
     [not found]   ` <20210905152253.3ea6beb3@jic23-huawei>
     [not found]     ` <7b93a51a-3856-63a8-20fb-e2b7f341254a@protonic.nl>
2021-09-08 17:08       ` Jonathan Cameron [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=20210908180826.7074161d@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=david@protonic.nl \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roan@protonic.nl \
    --cc=tomasz.duszynski@octakon.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).