From: Jonathan Cameron <jic23@kernel.org>
To: Liam Beguin <liambeguin@gmail.com>
Cc: peda@axentia.se, lars@metafoo.de, pmeerw@pmeerw.net,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, robh+dt@kernel.org
Subject: Re: [PATCH v2 3/8] iio: inkern: error out on unsupported offset type
Date: Wed, 9 Jun 2021 21:28:50 +0100 [thread overview]
Message-ID: <20210609212850.008d7f84@jic23-huawei> (raw)
In-Reply-To: <20210607144718.1724413-4-liambeguin@gmail.com>
On Mon, 7 Jun 2021 10:47:13 -0400
Liam Beguin <liambeguin@gmail.com> wrote:
> From: Liam Beguin <lvb@xiphos.com>
>
> iio_convert_raw_to_processed_unlocked() assumes the offset is an
> integer.
> Make that clear to the consumer by returning an error on unsupported
> offset types without breaking valid implicit truncations.
>
> Signed-off-by: Liam Beguin <lvb@xiphos.com>
> ---
> drivers/iio/inkern.c | 34 +++++++++++++++++++++++++++++-----
> 1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> index b69027690ed5..0b5667f22b1d 100644
> --- a/drivers/iio/inkern.c
> +++ b/drivers/iio/inkern.c
> @@ -578,13 +578,37 @@ EXPORT_SYMBOL_GPL(iio_read_channel_average_raw);
> static int iio_convert_raw_to_processed_unlocked(struct iio_channel *chan,
> int raw, int *processed, unsigned int scale)
> {
> - int scale_type, scale_val, scale_val2, offset;
> + int scale_type, scale_val, scale_val2;
> + int offset_type, offset_val, offset_val2;
> s64 raw64 = raw;
> - int ret;
>
> - ret = iio_channel_read(chan, &offset, NULL, IIO_CHAN_INFO_OFFSET);
> - if (ret >= 0)
> - raw64 += offset;
> + offset_type = iio_channel_read(chan, &offset_val, &offset_val2,
> + IIO_CHAN_INFO_OFFSET);
> + if (offset_type >= 0) {
> + switch (offset_type) {
> + case IIO_VAL_INT:
> + break;
> + case IIO_VAL_INT_PLUS_MICRO:
> + if (offset_val2 > 1000)
What's the logic behind this one? > 1000000
would be an interesting corner case, though I'm not sure we've ever
explicitly disallowed it before.
Why are we at 1000th of that for the check?
> + return -EINVAL;
> + break;
> + case IIO_VAL_INT_PLUS_NANO:
> + if (offset_val2 > 1000000)
Similar this is a bit odd.
> + return -EINVAL;
> + case IIO_VAL_FRACTIONAL:
> + if (offset_val2 != 1)
> + return -EINVAL;
We could be more flexible on this, but I don't recall any
channels using this so far.
> + break;
> + case IIO_VAL_FRACTIONAL_LOG2:
> + if (offset_val2)
> + return -EINVAL;
Same in this case.
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + raw64 += offset_val;
> + }
>
> scale_type = iio_channel_read(chan, &scale_val, &scale_val2,
> IIO_CHAN_INFO_SCALE);
next prev parent reply other threads:[~2021-06-09 20:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 14:47 [PATCH v2 0/8] iio: afe: add temperature rescaling support Liam Beguin
2021-06-07 14:47 ` [PATCH v2 1/8] iio: inkern: apply consumer scale on IIO_VAL_INT cases Liam Beguin
2021-06-07 14:47 ` [PATCH v2 2/8] iio: inkern: apply consumer scale when no channel scale is available Liam Beguin
2021-06-07 14:47 ` [PATCH v2 3/8] iio: inkern: error out on unsupported offset type Liam Beguin
2021-06-09 20:28 ` Jonathan Cameron [this message]
2021-06-09 21:40 ` Liam Beguin
2021-06-10 9:06 ` Jonathan Cameron
2021-06-10 20:42 ` Peter Rosin
2021-06-07 14:47 ` [PATCH v2 4/8] iio: inkern: return valid type on raw to processed conversion Liam Beguin
2021-06-09 20:32 ` Jonathan Cameron
2021-06-09 21:46 ` Liam Beguin
2021-06-10 9:08 ` Jonathan Cameron
2021-06-07 14:47 ` [PATCH v2 5/8] iio: afe: rescale: add upstream offset support Liam Beguin
2021-06-07 14:47 ` [PATCH v2 6/8] iio: afe: rescale: add " Liam Beguin
2021-06-07 14:47 ` [PATCH v2 7/8] iio: afe: rescale: add temperature sensor support Liam Beguin
2021-06-10 21:23 ` Peter Rosin
2021-06-07 14:47 ` [PATCH v2 8/8] dt-bindings: iio: afe: add binding for temperature-sense-amplifier Liam Beguin
2021-06-09 20:52 ` Jonathan Cameron
2021-06-09 21:50 ` Liam Beguin
2021-06-11 7:37 ` Peter Rosin
2021-06-11 16:12 ` Liam Beguin
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=20210609212850.008d7f84@jic23-huawei \
--to=jic23@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lars@metafoo.de \
--cc=liambeguin@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.org \
/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