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, 03 Mar 2010 19:45:12 +0000
From:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>
To:	Manu Abraham <abraham.manu@...il.com>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Dima Zavin <dmitriyz@...gle.com>,
	Jonathan Cameron <jic23@....ac.uk>,
	LKML <linux-kernel@...r.kernel.org>,
	Zhang Rui <rui.zhang@...el.com>,
	Amit Kucheria <amit.kucheria@...durent.com>,
	Jean Delvare <khali@...ux-fr.org>, Greg KH <greg@...ah.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-iio@...r.kernel.org
Subject: Re: [GIT PULL] Ambient Light Sensors subsystem

Hi Manu,

...
> Maybe it make sense to put all Generic sensors into one whole lot,
> where an application can
> 
> - read the value from the driver (eg: 0 - 65535)
> 
> - read from device static information (to identify how the application
> should treat the values read back.)
> 
>    - report what type of device it is (Light, Voltage, Acceleration
> and what not, simple enumeration will help, mayeb you can even have
> bitwise OR the types, so that you can have a driver with multiple
> capabilities)
>    - the max value it can go
>    - the min value it can go
>    - the number of steps (gradient) that the driver can do.
> 
> 
> Maybe such a simplistic interface does help ?
> 
> The application can simply read the static information from the driver
> and decide whether it should really handle that driver class.

The more generic sensors are covered by IIO (in staging)
There is a lot more there as well as an equivalent of what you describe.

The simplest equivalent to this is the hwmon subsystem (from which IIO
has borrowed a lot of interfaces, as has ALS).

You have a sysfs file per channel, so taking als api as an example:

illuminance0 - Value of illuminance in lux.

If you want your other elements (though no driver provides them at the moment).

illuminance0_max
illuminance0_min
illuminance0_values

For slow devices this is all you need.
If you are interested in fast devices, take a look at the recently posted IIO ABI spec.
That uses sysfs files to describe the data that can be read from a character device
that is fed from a buffer (either hardware or software). It also supports fairly
advanced event handling (similar to input, but without cross device aggregation)
and triggering of data capture from various 'interrupt' sources.

It is still somewhat unclear how exactly to marry the high speed data acquisition
requirements with other 'client' subsystems such as input. All suggestions on that
are welcome! 

Jonathan

(cc'd linux-iio)
--
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/