linux-kernel - Re: [PATCH] staging:iio:proof of concept in kernel interface.

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] [day] [month] [year] [list]

Message-ID: <4E9C362B.3080502@cam.ac.uk>
Date:	Mon, 17 Oct 2011 15:05:31 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Linus Walleij <linus.ml.walleij@...il.com>,
	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
	zdevai@...il.com
Subject: Re: [PATCH] staging:iio:proof of concept in kernel interface.

On 10/17/11 14:55, Mark Brown wrote:
> On Mon, Oct 17, 2011 at 02:03:53PM +0100, Jonathan Cameron wrote:
>> On 10/17/11 13:48, Mark Brown wrote:
> 
>>>> 0...4
>>>> 1...5
>>>> AUXA....AUXD
>>>> TEMP_EXT1...TEMP_EXT5 (all of which are just normal adc channels that some
>>>> designer decided would be used only for connecting analog temperature sensors.)
> 
>>> None of those look at all unreasonable
> 
>> Fair enough though the temp one is at least stupid, but why should
>> we match them?
> 
> So that the engineer sitting there with the schematics can figure out
> how to tell software about the board hookup with minimal pain.
Fine, I'll code it up and we'll see what works for the cases we have.
> 
>> Ok, so we could add to every channel a magic matching field called
>> datasheet_name?  To my mind its silly overhead, but if there is a
>> consensus on it then fine.  Note however that any remotely general
>> purpose userspace will not read these values even if we make
>> them available.
> 
> That depends, if the userspace is really general purpose I'd expect it'd
> be exposing this information to let the user point and click (or
> whatever) through the channels.  Otherwise they'll be scratching their
> heads wondering what channel 0 on this particular system actually is.
> 
True enough, though ultimately it would be nice if it is easy enough to
work out that they can put sticky labels on the wires...  Lets call these
channel_label and keep them optional for now. If nothing else I don't
really fancy retrofitting our 50+ existing drivers with them all in
one go.

Jonathan

--
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/