[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 03 Mar 2010 11:19:21 +0000
From: Jonathan Cameron <jic23@....ac.uk>
To: Linus Walleij <linus.ml.walleij@...il.com>
CC: Dima Zavin <dmitriyz@...gle.com>, torvalds@...ux-foundation.org,
LKML <linux-kernel@...r.kernel.org>,
Zhang Rui <rui.zhang@...el.com>,
Amit Kucheria <amit.kucheria@...durent.com>,
Jean Delvare <khali@...ux-fr.org>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem
On 03/03/10 10:30, Linus Walleij wrote:
> 2010/3/3 Dima Zavin <dmitriyz@...gle.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!)
--
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/
Powered by blists - more mailing lists