All of lore.kernel.org
 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 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.