lkml.org 
[lkml]   [2010]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Ambient Light Sensors subsystem
On 03/03/10 10:30, Linus Walleij wrote:
> 2010/3/3 Dima Zavin <dmitriyz@google.com>:
>
>> how does this deal with hybrid devices?
>
> As any hybrid device, a drivers/mfd spawns multiple sensors, als,
> accelerometer, voltage level, you name it.
>
>> I definitely see the need for what you guys are trying to accomplish.
>> For example, currently, we use an input device for reporting events,
>> and a separate misc device node for control
>> (enable/disable/configure). It's definitely suboptimal, but there
>> currently isn't anything there would let us do things cleanly.
>
> Are you registering your misc node from an mfd device then?
>
>> I would love to work with you to design something more generic.
>
> You can design forever, people need this now. (But we'd love
> to see the patches!) It's better to refactor the day something
> better is in place IMHO. Also I see no real clash. The userspace
> interface will likely be the same (input subsystem) so what's the
> problem?
>
> In the drivers/staging/iio in the -next tree you can find something
> more generic for industrial I/O including ADCs, triggers and
> some sensors. I pointed out sometime last month that this
> has the problem of exposing only userland interfaces and no
> kernel-internal interfaces for the actual devices (just sysfs entries),
> so the current ALS subsystem cannot fit into it, for example.

We welcome patches for that as well ;)

(It is definitely on the todo list, but I'm afraid not terribly
near the top from my point of view as I don't personally need it!)


\
 
 \ /
  Last update: 2010-03-03 12:19    [W:0.149 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site