From: Jonathan Cameron <jic23@kernel.org>
To: Puranjay Mohan <puranjay12@gmail.com>
Cc: Michael.Hennerich@analog.com, devicetree@vger.kernel.org,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
lars@metafoo.de, Dragos.Bogdan@analog.com,
Darius.Berghe@analog.com, andy.shevchenko@gmail.com,
Alexandru Ardelean <ardeleanalex@gmail.com>
Subject: Re: [PATCH v12 2/2] iio: accel: Add driver support for ADXL355
Date: Sun, 15 Aug 2021 16:46:54 +0100 [thread overview]
Message-ID: <20210815164654.3c51a8e3@jic23-huawei> (raw)
In-Reply-To: <20210811073027.124619-3-puranjay12@gmail.com>
On Wed, 11 Aug 2021 13:00:27 +0530
Puranjay Mohan <puranjay12@gmail.com> wrote:
> ADXL355 is a 3-axis MEMS Accelerometer. It offers low noise density,
> low 0g offset drift, low power with selectable measurement ranges.
> It also features programmable high-pass and low-pass filters.
>
> Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/adxl354_adxl355.pdf
> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Puranjay Mohan <puranjay12@gmail.com>
Hi Puranjay,
I took one last look at this so I can apply it without looking again assuming
the dt review is fine. Noticed one issue with error handling, but I can tidy
that up whilst applying assuming you aren't doing a v13 for some other reason.
If you are please incorporate these changes as well.
Thanks,
Jonathan
...
> +
> +static int adxl355_set_odr(struct adxl355_data *data,
> + enum adxl355_odr odr)
> +{
> + int ret = 0;
> +
> + mutex_lock(&data->lock);
> +
> + if (data->odr == odr)
> + goto out_unlock;
> +
> + ret = adxl355_set_op_mode(data, ADXL355_STANDBY);
> + if (ret < 0)
> + goto out_unlock;
> +
> + ret = regmap_update_bits(data->regmap, ADXL355_FILTER_REG,
> + ADXL355_FILTER_ODR_MSK,
> + FIELD_PREP(ADXL355_FILTER_ODR_MSK, odr));
> + if (ret < 0)
> + goto out_unlock;
> +
> + data->odr = odr;
> + adxl355_fill_3db_frequency_table(data);
> +
> +out_unlock:
> + ret = adxl355_set_op_mode(data, ADXL355_MEASUREMENT);
As below, we should do this because it risks returning success when a failure
actually occured. Again, unless you are respinning for some other reason I'll
add the logic whilst applying.
> + mutex_unlock(&data->lock);
> + return ret;
> +}
> +
> +static int adxl355_set_hpf_3db(struct adxl355_data *data,
> + enum adxl355_hpf_3db hpf)
> +{
> + int ret = 0;
> +
> + mutex_lock(&data->lock);
> +
> + if (data->hpf_3db == hpf)
> + goto unlock;
> +
> + ret = adxl355_set_op_mode(data, ADXL355_STANDBY);
> + if (ret < 0)
> + goto set_opmode_unlock;
> +
> + ret = regmap_update_bits(data->regmap, ADXL355_FILTER_REG,
> + ADXL355_FILTER_HPF_MSK,
> + FIELD_PREP(ADXL355_FILTER_HPF_MSK, hpf));
> + if (!ret)
> + data->hpf_3db = hpf;
> +
> +set_opmode_unlock:
> + ret = adxl355_set_op_mode(data, ADXL355_MEASUREMENT);
We can't do this as it might potentially eat an error that meant the regmap
update didn't occur. To avoid that a little dance is needed using a second
return value and we only set ret = ret2 if ret == 0
Alternatively we just have a separate error handling path which doesn't set
ret for the adxl355_set_op_mode(). I'll probably go with that as it's more
code but easier to read.
> +unlock:
> + mutex_unlock(&data->lock);
> + return ret;
> +}
> +
...
> +static int adxl355_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct adxl355_data *data = iio_priv(indio_dev);
> + int odr_idx, hpf_idx, calibbias;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + odr_idx = adxl355_find_match(adxl355_odr_table,
> + ARRAY_SIZE(adxl355_odr_table),
> + val, val2);
> + if (odr_idx < 0)
> + return odr_idx;
> +
> + return adxl355_set_odr(data, odr_idx);
> + case IIO_CHAN_INFO_HIGH_PASS_FILTER_3DB_FREQUENCY:
> + hpf_idx = adxl355_find_match(data->adxl355_hpf_3db_table,
> + ARRAY_SIZE(data->adxl355_hpf_3db_table),
Mixing different indentation styles isn't very nice for readability.
I'll tweak this whilst applying.
> + val, val2);
> + if (hpf_idx < 0)
> + return hpf_idx;
> +
> + return adxl355_set_hpf_3db(data, hpf_idx);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + calibbias = clamp_t(int, val, S16_MIN, S16_MAX);
> +
> + return adxl355_set_calibbias(data, chan->address, calibbias);
> + default:
> + return -EINVAL;
> + }
> +}
...
next prev parent reply other threads:[~2021-08-15 15:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 7:30 [PATCH v12 0/2] iio: accel: add support for ADXL355 Puranjay Mohan
2021-08-11 7:30 ` [PATCH v12 1/2] dt-bindings: iio: accel: Add DT binding doc " Puranjay Mohan
2021-08-14 18:13 ` Puranjay Mohan
2021-08-17 21:10 ` Rob Herring
2021-08-11 7:30 ` [PATCH v12 2/2] iio: accel: Add driver support " Puranjay Mohan
2021-08-15 15:46 ` Jonathan Cameron [this message]
2021-08-15 16:29 ` Puranjay Mohan
2021-08-18 9:11 ` Jonathan Cameron
2021-08-19 17:17 ` Puranjay Mohan
2021-08-11 16:01 ` [PATCH v12 0/2] iio: accel: add " Andy Shevchenko
2021-08-12 4:26 ` Puranjay Mohan
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=20210815164654.3c51a8e3@jic23-huawei \
--to=jic23@kernel.org \
--cc=Darius.Berghe@analog.com \
--cc=Dragos.Bogdan@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy.shevchenko@gmail.com \
--cc=ardeleanalex@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=puranjay12@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 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).