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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100304102258.75d2f356@hyperion.delvare>
Date:	Thu, 4 Mar 2010 10:22:58 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Dima Zavin <dmitriyz@...gle.com>
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

On Wed, 3 Mar 2010 15:08:29 -0800, Dima Zavin wrote:
> > 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/...).

I don't disagree.

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

The light sensor I have (TSL2550) is stupid and doesn't offer anything
other than slow polling. Not thresholds, no interrupts, nothing. This
is where the sysfs interface originates from. The very point of
grouping light sensor drivers together is to get a better view of what
the devices offer, and from there, of what interfaces make sense.

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

Sure I know.

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