linux-kernel - Re: [RFC PATCH 00/21] IIO: Channel registration rework, buffer chardev combining and rewrite of triggers as 'virtual' irq

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:	Mon, 04 Apr 2011 14:26:56 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Jonathan Cameron <jic23@....ac.uk>
CC:	michael.hennerich@...log.com,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"device-drivers-devel@...ckfin.uclinux.org" 
	<device-drivers-devel@...ckfin.uclinux.org>
Subject: Re: [RFC PATCH 00/21] IIO: Channel registration rework, buffer chardev
 combining and rewrite of triggers as 'virtual' irq_chips.

On 04/04/11 14:17, Jonathan Cameron wrote:
> On 04/04/11 13:02, Michael Hennerich wrote:
>> On 03/31/2011 04:53 PM, Jonathan Cameron wrote:
>>> Dear All,
>>>
>>> I'm afraid what in many ways makes sense as three separate
>>> series have gotten rather intertwined.  I can probably unpick
>>> them but it will involve a lot of intermediate code in
>>> lis3l02dq (which is our fiddly example for this set) that I'd
>>> rather avoid.  Hence lets have a guide to what various people
>>> might be interested in:
>>>
>>> 1) Channel registration rework (this has previous been in linux-iio
>>>    but really comes into it's own after we remove various special
>>>    cases later in this code).
>>>
>>>    Patches 1, 2, 3, 21
>>>    (8) - cleanups Arnd Bergmann pointed out in passing.
>>>   
>> Good approach. It removes quite a bit on duplicated code across drivers.
>> At the moment I can't think of existing drivers that couldn't moved over
>> to the
>> new channel registration method.
> There are a few that will require quite a bit more code - principally the
> light sensors with their rather odd channel naming.  I'll do one of those
> shortly and see what we end up with.
> 
>> However there are some limitations.
>> read_raw() value is currently type int, depending on the channel type,
>> int type might be too short.
> True. How far do you think we should go?  s64? I did wonder if it makes sense
> to have two value pointers (perhaps NULL)  So base unit (val1) and
> decimal places of base unit (val2).
> 
> So true raw values (e.g. sensor readings) will only set val1, but we have plenty
> of space for things like scale at sufficient accuracy.  That also means we can
> flatten together the attributes in the core for both cases (not a great saving
> but nice to have none the less).
Oops, obviously if we do combine the functions then passing NULL pointers is
nonsensical. Perhaps the return value can indicate which parts are meaningful.
> 
> What do you think?
> 
--
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/