linux-kernel - Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 21 Oct 2016 10:24:24 +0200
From:   Peter Rosin <peda@...ntia.se>
To:     <jic23@...nel.org>
CC:     Jonathan Cameron <jic23@...23.retrosnub.co.uk>,
        Lars-Peter Clausen <lars@...afoo.de>,
        <linux-kernel@...r.kernel.org>, Hartmut Knaack <knaack.h@....de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        <linux-iio@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-iio-owner@...r.kernel.org>
Subject: Re: [PATCH 0/4] IIO wrapper drivers, dpot-dac and envelope-detector

On 2016-10-21 09:17, jic23@...nel.org wrote:
> On 20.10.2016 19:17, Peter Rosin wrote:
>> On 2016-10-20 19:37, Jonathan Cameron wrote:
>>> http://marc.info/?l=linux-iio&m=138469765309868&w=2 I think...
>>
>> Interesting, one issue with that is that it is all in real world
>> units, while I'd rather have the raw value.
> Um.. It's been a while, but the principle was (IIRC) that every
> _available would match the units fo the associated info mask element.
> Thus if you have a _raw element it would be in adc counts (most likely).
> 
> _input would be in relevant real world units, scale etc in the whatever
> units the value itself is in.

Ah, that was just me totally misreading the patch. I didn't realize
that the iio_format_value function is also used for raw values and
assumed it was all about real world units when that function was
used. Feel rather silly ATM...

>> So, I would need to
>> convert back to the raw value using the scale, which sounds boring
>> but doable. However, I wonder if calibration may also be involved
>> with that conversion back to raw for some channels? That sounds a
>> bit more driver specific and potentially troublesome...
> I've not had a chance to look at your code (only picked up on this as
> there was a fair length thread developing), but I wouldn't have thought 
> we'd
> need to deal with calibrations.   Might need them to move to real world
> units from raw but that's always the case anyway (unfortunately).

Right.

Cheers,
Peter