Re: [GIT PULL] Ambient Light Sensors subsystem

[Jean Delvare]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/