linux-kernel - Re: RFC: Light sensors, unifying current options?

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:	Thu, 10 Sep 2009 09:34:09 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Jean Delvare <khali@...ux-fr.org>,
	"alan@...ux.intel.com" <alan@...ux.intel.com>,
	"lenb@...nel.org" <lenb@...nel.org>, "pavel@....cz" <pavel@....cz>,
	"Cory T. Tusar" <ctusar@...eon-central.com>,
	"Trisal, Kalhan" <kalhan.trisal@...el.com>,
	linux-acpi <linux-acpi@...r.kernel.org>
Subject: Re: RFC: Light sensors, unifying current options?

On Wed, 2009-09-09 at 19:28 +0800, Jonathan Cameron wrote:
> Zhang Rui wrote:
> > On Mon, 2009-09-07 at 19:42 +0800, Jonathan Cameron wrote:
> >> Zhang Rui wrote:

> >
> >> Maybe similar to hwmon approach allowing for multiple readings of a given
> >> type?
> >>
> >> illumiance[n]
> >> illuminmance_type[n]
> >
> > what's the value in illuminance_type, infrared/visible/ultraviolet?
> Probably a mask allowing for a given sensor to cover several of these.
> Hence if you have an infrared and an visible + infrared, userspace can
> pull the visible out.  Or we could do that separation in kernel, so
> in this case export
> 
> visible, visible+infrared and infrared.
> 
> Perhaps we might do it via sysfs naming instead.
> 
> illuminance[n] - defined to be visible (which is what term means anyway)
> 
> infrared[n] - hmm.. will be in different units to illuminance - perhaps we leave
> these raw with suitable documentation?
> 
> illuminance_and_infrared[n]
> 
what's the unit of this?
what does the value of this file mean?
I think we should make sure that there are more sensors need this and
the same "visible + infrared" reading on different sensors stands for
the same ambient light environment.
Or else we should convert it to something generic. what do you think?

>   If they are capable of
> exporting other things all well and good.  The naming can be decided as and
> when people post drivers with new functionality.
> 

> The other obvious question is whether it makes sense to cache values from sensors?
> (as per many hwmon drivers)  These things are pretty slow, so there is no point in
> taking a new reading unless there has been sufficient time for it to update.
> Still this is again a documentation issue rather than core code, as it would be
> down to the individual drivers.
> 

I think this depends and it's the individual drivers responsibility to
keep these values valid.

For example, ACPI ALS can get a notification "whenever the lux reading
changes more than 10% (from the last reading that resulted in a
notification)". So it can use cache values because they're refreshed
from time to time.

But maybe there are some other sensors that don't have this asynchronous
notification so that the cached values don't have a chance to get
updated.
then we need to read the sensor every time the sysfs I/F is poked.

thanks,
rui


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