| 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
| ||
|
Date: Thu, 4 Mar 2010 00:08:21 +0400 From: Manu Abraham <abraham.manu@...il.com> To: Jonathan Cameron <kernel@...23.retrosnub.co.uk> 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 On Wed, Mar 3, 2010 at 11:45 PM, Jonathan Cameron <kernel@...23.retrosnub.co.uk> wrote: > 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 Just as i thought: A Class with values to define floor and ceiling and the gradient in which the driver can provide such an information in a generic way, rather than limiting to Ambient Light Sensor. to make it a bit more stylistic, you could provide static information, such as driver name also alongwith. But in any case, i guess you wouldn't need more than these device_name max_val min_val gradient/steps as static information and a simple value that could be read back. In (some remote thought) addition, some devices could "possibly" have levels that you could set the levels at which the device could set of a trigger, in which case, you might want to write to the driver to set the value at which you want to trigger of some event. (Don't really know whether this is applicable, but I have seen it in some temperature sensors, such a feature) > 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! I don't know how fast is "fast". "I think", (based on quick thought) all you might need is a trigger, whether the userspace application needs to be triggered to read the value from the driver, or do something exotic. ie the trigger is a binary only event, as I understand, right ? But in any case, you define the trigger mechanism in any way, similar to an interrupt The data to be read back could be just as generic, in any case, rather than defining a subsystem per device category.. Regards, Manu -- 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/
Powered by blists - more mailing lists