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]

Date:	Wed, 3 Mar 2010 15:08:29 -0800
From:	Dima Zavin <dmitriyz@...gle.com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Zhang Rui <rui.zhang@...el.com>,
	Amit Kucheria <amit.kucheria@...durent.com>
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem

> Honestly, I don't care. The light sensor drivers can live wherever you
> want and use whatever interface you want, I don't give a damn. What I
> really want is that:
> 1* All light sensor drivers live at the same place in the kernel tree,
>   so that people looking for them know where to look.
> 2* drivers/i2c/chips dies. Meaning that, if the tsl2550 driver has not
>   moved away from drivers/i2c/chips by rc1, I'll move it myself, manu
>   militari, to drivers/misc.

Please do kill i2c/chips. I've tried to follow suite with your
campaign and have been pushing vendors on my end to not dump their
drivers in there. However, wanting to clean up the directory structure
is not a good reason to create a new interface to userspace. And
furthermore, the proposed directory structure changes are not really
that scalable imho (e.g. drivers/sensors/als would make a lot more
sense to me than to pollute the top level drivers/...).

As it came up earlier in the thread, adding an ABS_AMBIENT_LIGHT_LEVEL
or equivalent is much simpler and provides a clean, concise, and
useful interface to userspace.

Note that for many applications, you actually get configurable
threshold levels, and the hardware triggers an interrupt when the
light level crosses those thresholds. This makes using an input device
very useful, and that is in fact how we use ALS devices today. I have
several pieces of hardware that do this, and I don't see how this new
als subsystem helps me handle that problem. With the suggested API,
I'll have to poll the sysfs files manually to see if they've changed
(which is suboptimal), or still add a non-standard input device to do
what I want.

> I am a little sad to see two discussions about the ALS subsystem right
> in the middle of the merge window, one about what the interface should
> be and one about what the subsystem should include, while discussions
> about these two points have been ongoing publicly for 5 months now. I
> really want things (whatever they are) happen now and not in another 5
> months.

I'm sorry I missed the previous discussion, so please accept my
apologies. I was very busy with work at that time, I'm sure you know
how that goes.

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