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]

Message-ID: <58b9c20d-6c3c-4693-b073-e5a8f9c4cb94@axentia.se>
Date:   Sat, 22 Oct 2016 00:58:27 +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:
>>> On 20 October 2016 18:30:19 BST, Jonathan Cameron 
>>> <jic23@...23.retrosnub.co.uk> wrote:
>>>> On 20 October 2016 13:55:12 BST, Lars-Peter Clausen <lars@...afoo.de> 
>>>> wrote:
>>>>> On 10/20/2016 11:25 AM, Peter Rosin wrote:
>>>>>> Also, is there some agreed-upon way to dig out the maximum value 
>>>>>> from
>>>>>> an iio channel? If so, "dpot-dac,max-ohms" can be eliminated from 
>>>>>> the
>>>>>> dt bindings, which would have been nice...
>>>>>
>>>>> Yes, this is something we could really use. In a sense it exists for
>>>>> the
>>>>> devices with buffer-capable channels where there is the real_bits 
>>>>> field
>>>>> which tells us the data width of the channel. But a dedicated 
>>>>> mechanism
>>>>> for
>>>>> querying the maximum (and minimum) valid code seems like a useful
>>>>> feature.
>>>>> Not only for in-kernel clients, but also for userspace.
>>>>
>>>> This was something that was addressed by the rather ancient patch
>>>> series i posted that added
>>>> an available call back which provided info on range and values for 
>>>> all info mask elements.
>>>> Series got buried by there being a lot of precursors but quite a few of
>>>> those have merged since.
>>>>
>>>> Hmm Google won't let me find it on my phone. Was a while back now. 
>>>> Will
>>>> try to get on pc with
>>>> decent email archive later and dig out a reference.
>>> 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.

Ok, so I forward ported that patch and added code so that the relevant
channels provide what is available. I also added code to turn the
rest of the parameter style devicetree properties into iio device/channel
attributes. So, it is now much neater from a bindings point of view.

Before I post the updated patches, I'm wondering what the status is
on that ancient patch? It didn't forward port without issues, but there
were no real difficulties that I noticed. Should I just start off my v2
series with that patch? I tend to think that that's the best option,
because I suspect that adding a "max-ohms" devicetree property as a
stop-gap pending some new infrastructure is pretty unrealistic...

Basically, my question is if that ancient patch as any chance of living
at all in a form close to what it is, or if should start looking for
an alternative right away?

Cheers,
Peter