linux-kernel - Re: [GIT PULL] Ambient Light Sensors subsystem

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]

Message-ID: <404ea8001003080158w6a747cbfv9475e32976ccf9e2@mail.gmail.com>
Date:	Mon, 8 Mar 2010 01:58:26 -0800
From:	Dima Zavin <dmitriyz@...gle.com>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	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

Jonathan,

> Anyhow, the way this conversation is going there appear to be several options
> and we need to make a decision before anyone wastes much more time.
>
> 1) ALS as is. It's extremely light weight and can always be merged with a better
>  option at a later date. If people prefer we can always stick it in a subdirectory
>  called sensors or similar.  Perhaps move hwmon in there as well.

If your plan is to integrate with iio when it's ready, then there will
be a drivers/iio, so creating top-level als or even drivers/sensors at
this point wouldn't really make sense. Perhaps putting them into
drivers/misc/als is more appropriate?

> 2) Input.  I agree with Dmitry here.  These devices are not within the scope as it
>  currently exists.  It can be done and there have been numerous discussions about
>  doing so in the past (with various sensor types) and each time it has been decided
>  that it isn't the right option.  Perhaps opinion on this has changed?

As Dmitry correctly distilled from my ramblings, what we really need
is support for poll() on sensor devices. If you guys add a poll
interface to als, then we can probably get by until iio gets merged.
Otherwise, we will still need to hack up an input device exporting
ABS_MISC. If we had ABS_AMBIENT_LIGHT_LEVEL, then it'd be slightly
less hacky.

> Please can anyone who feels like suggesting another general sensors subsystem
> at least taking a look at IIO (and keeping in mind we are in the middle of a big
> API cleanup).  If you disagree with how we have done things, then contribute
> to the discussions and they may change.

I looked into IIO (sorry for the delay), and it does look promising.
I'll try to participate in future discussions, and will provide some
more feedback in a more appropriate forum as it is likely out of scope
here. When I get a chance, I'll try moving one of our drivers to iio
and see how it goes.

Thanks.

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