linux-kernel - Re: [PATCH v2] iio: afe: rescale: Accept only offset channels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 16 Oct 2023 14:54:24 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Peter Rosin <peda@...ntia.se>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Liam Beguin <liambeguin@...il.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] iio: afe: rescale: Accept only offset channels

On Mon, Oct 16, 2023 at 12:05 PM Peter Rosin <peda@...ntia.se> wrote:

> > Just raw (with neither offset or rescale) doesn't make sense, since
>
> And I don't see why not. That's the crux.

OK I can implement that, but then we need to define the priority of
"just raw" vs "processed". It is quite common that ADC drivers
provide raw and processed. Which one goes first?

Right now the priority is:

1. Raw + scale, if scale exists else
2. Processed

After this patch the priority would be:

1. Raw+scale OR Raw+offset if either scale or offset exists else
2. Processed

How do you expect a raw channel to be prioritized?

I can only put it last, as putting it second would break existing users
that provide both raw and processed. Is this how you imagine this
to work?

Further, that could be a separate patch on top of this so it is a little
bit of feature creepy to push into this patch, but I can make a 2-patch
series if you like. It basically does not block applying this one patch
on the way there.

> > the AFE rescaler does just offsetting and rescaling, in that case the
> > user should just use the raw channel. Also it would then take
> > precedence over a processed channel (which applies rescale and
> > offset internally) which doesn't make sense to me.
>
> Why isn't it perfectly fine for a device to provide only a raw
> channel and then expect that to be interpreted as the real unit?

You're right there is no problem with that.

The only problem I have with it is how to prioritize it.

Would need Jonathan's feedback here too though, I might be
missing something.

> Why would it need a processed channel when no processing is
> going on? E.g. a device reporting the temp in the expected unit
> in one of its registers. Or whatever with such a friendly
> register.

Good point.

Unless someone would call that a "processed channel" albeit
processed in hardware. But this definition of raw == raw register
reads works for me.

> > I'm not sure I fully understood the remark, please elaborate if I got it wrong!
>
> I agree that the patch does exactly as you intend. I question if
> what you intend is correct, but since I don't know the rules, I'd
> simply like to have the rules clarified.

Like I know the rules :D

Whenever I do anything in IIO I feel like Socrates, all I know is
that I know nothing.

Yours,
Linus Walleij