From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jonathan Cameron <jic23@kernel.org>,
Mighty <bavishimithil@gmail.com>, <lars@metafoo.de>,
<liambeguin@gmail.com>, <linux-iio@vger.kernel.org>,
<peda@axentia.se>, <stable@vger.kernel.org>
Subject: Re: [PATCH] iio: afe: rescale: Fix logic bug
Date: Tue, 29 Aug 2023 12:37:42 +0100 [thread overview]
Message-ID: <20230829123742.0000033e@Huawei.com> (raw)
In-Reply-To: <CACRpkdZXBjHU4t-GVOCFxRO-AHGxKnxMeHD2s4Y4PuC29gBq6g@mail.gmail.com>
On Tue, 29 Aug 2023 09:17:00 +0200
Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Aug 28, 2023 at 8:18 PM Jonathan Cameron <jic23@kernel.org> wrote:
>
> > Not 100% the follow is relevant as I've lost track of the discussion
> > but maybe it is useful.
> >
> > Worth noting there are a few reasons why RAW and PROCESSED can coexist
> > in drivers and indeed why SCALE can be absent.. (OFFSET is much the same)
>
> That's fine. If we have PROCESSED the rescaler will use that first.
>
> What we're discussing are channels that have just RAW
> and no PROCESSED, nor SCALE or OFFSET yet are connected to
> a rescaler.
>
> > 1) If SCALE = 1.0 the driver is allowed not to provide it - the channel
> > might still be raw if OFFSET != 0
>
> I'm not so sure the rescaler can handle that though. Just no-one
> ran into it yet...
>
> > 2) If the channel has a horrible non linear and none invertable conversion
> > to standard units and events support the you might need PROCESSED to
> > provide the useful value, but RAW to give you clue what the current value
> > is for setting an event (light sensors are usual place we see this).
> >
> > 3) Historical ABI errors. If we first had RAW and no scale or offset because
> > we had no known values for them. Then later we discovered that there
> > was a non linear transform involved (often when someone found a magic
> > calibration code somewhere). Given the RAW interface might be in use
> > and isn't a bug as such, we can't easily remove it. The new PROCESSED
> > interface needs to be there because of the non linear transform..
> >
> > Odd corner cases... In this particular case the original code made no
> > sense but might have allowed for case 3 by accident?
>
> I think it's fine, we make PROCESSED take precedence in all cases
> as long as SCALE is not there as well.
>
> rescale_configure_channel() does this:
>
> if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) &&
> iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE)) {
> dev_info(dev, "using raw+scale source channel\n");
> } else if (iio_channel_has_info(schan, IIO_CHAN_INFO_PROCESSED)) {
> dev_info(dev, "using processed channel\n");
> rescale->chan_processed = true;
> } else {
> dev_err(dev, "source channel is not supported\n");
> return -EINVAL;
> }
>
> I think the first line should be
>
> if (iio_channel_has_info(schan, IIO_CHAN_INFO_RAW) &&
> (iio_channel_has_info(schan, IIO_CHAN_INFO_SCALE ||
> iio_channel_has_info(schan,IIO_CHAN_INFO_OFFSET)))
>
> right? We just never ran into it.
Makes sense to me.
Jonathan
>
> Yours,
> Linus Walleij
next prev parent reply other threads:[~2023-08-29 11:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 7:54 [PATCH] iio: afe: rescale: Fix logic bug Linus Walleij
2022-05-25 14:08 ` Peter Rosin
2022-05-26 1:29 ` Liam Beguin
2022-05-28 17:01 ` Jonathan Cameron
2023-08-09 13:43 ` Mighty
2023-08-10 8:56 ` Linus Walleij
2023-08-21 16:45 ` Mighty
2023-08-23 8:21 ` Linus Walleij
2023-08-24 7:39 ` Mighty
2023-08-24 8:24 ` Linus Walleij
2023-08-24 8:28 ` Linus Walleij
2023-08-28 18:18 ` Jonathan Cameron
2023-08-29 7:17 ` Linus Walleij
2023-08-29 11:37 ` Jonathan Cameron [this message]
2023-09-03 17:10 ` Mighty
2023-09-04 7:20 ` Linus Walleij
2023-09-03 18:04 ` Mighty
2023-09-04 7:25 ` Linus Walleij
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=20230829123742.0000033e@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=bavishimithil@gmail.com \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=liambeguin@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-iio@vger.kernel.org \
--cc=peda@axentia.se \
--cc=stable@vger.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;
as well as URLs for NNTP newsgroup(s).