linux-kernel - Re: IIO comments

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, 18 Mar 2011 16:29:16 +0000
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Kay Sievers <kay.sievers@...y.org>, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org, Greg KH <greg@...ah.com>,
	Jean Delvare <khali@...ux-fr.org>,
	Guenter Roeck <guenter.roeck@...csson.com>
Subject: Re: IIO comments

On 03/18/11 16:18, Arnd Bergmann wrote:
> On Friday 18 March 2011, Jonathan Cameron wrote:
>> On 03/18/11 12:47, Arnd Bergmann wrote:
>>> On Thursday 17 March 2011, Jonathan Cameron wrote:
>>>> On 03/17/11 17:51, Arnd Bergmann wrote:
>>>>> I don't completely understand the notation. Regarding the various
>>>>> {in0, in1, in2, ...} inputs, is there a fundamental difference between
>>>>> them? In the code example I gave, a driver would simply list
>>>>> a set of inputs of the same type (IIO_CHAN_IN) and let the core
>>>>> enumerate them. What does "in0-in1" mean?
>>>>
>>>> in0-in1 is a differential adc channel. Literally outputs value on
>>>> physical pin 1 subtracted from physical pin 2.
>>>
>>> Ok, I see. So these would be fairly hard to enumerate, right?
>>> Would it be possible to have one attribute with named "diff%d"
>>> and another attribute associated with it that describes which
>>> channels are compared?
>>
>> Could do, but what would it gain us?  If the information is available
>> to the core, then it can use it give us the explicit naming? As shown
>> below we have to handle holes in the enumeration anyway so this isn't
>> to much of a problem.
> 
> Maybe I was seeing problems that don't exist here. Wouldn't
> you need to numeric identifiers to describe a differential
> channel?
Agreed, but from the point of view of what is exposed in naming it doesn't
matter.  The core and the driver need that number. Userspace doesn't.

Also note that we'll need to pass over an explicit index for the buffering
order anyway so what is one more.  The buffering one we can't avoid as
userspace has to know what it is and they are sometimes dependent on
really esoteric rules on the hardware.   Right now we assume that
there aren't sets with different contents where the ordering
of any given pair changes.  I think that is probably valid.
Hence what we have won't allow

a b c and b a d (in some sense they have to have a monotonic index).

> I guess if it's always in${i}-in${i+1}, it's still not too hard.
I think they have been so far, but doubt this is universal.
How about having a diff type and just having a pair of indices in the
channel structure?  Actually may need a third for x^2+y^2+z^2 devices.
(iirc there are parts that do x^2+y^2 despite also having a z channel)
...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/