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]

Message-ID: <4AA8D07C.1000600@cam.ac.uk>
Date:	Thu, 10 Sep 2009 11:10:04 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Pavel Machek <pavel@....cz>
CC:	Zhang Rui <rui.zhang@...el.com>,
	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>,
	"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?

Pavel Machek wrote:
> Hi!
> 
>>> 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.
> 
> Are you sure that makes sense? And is that even possible? I'd be
> afraid that the sensors are not nearly accurate enough to give precise
> values, and each sensor is going to take different parts of spectrum,
> etc.
> 
> Yes, we should aim at having similar interface with similar values on
> all the sensors, but lets not overdo it.
Agreed, if we match on the illuminance, pretty much everything else can
initially be chip dependent as long as they are sufficiently documented.
If certain things keep repeating then they can be standardized as and when
this occurs.
 
>> 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.
> 
> I bet most sensors are like that. And no, we don't have to reread from
> hw every time, we can just read and cache it once per second or
> something.
The ones I've seen in embedded devices tend to have some sort of interrupt
system, but it's reasonably complicated to configure as you have to read the
sensor then write threshold values back to get the same sort of notifications
as acpi is doing.  Also, it's far from unusual for people not to bother connecting
the interrupt pin up in the first place so we can't have those drivers relying on its
presence.

I think we are getting to the point where the easiest way to work out further
issues is going to be in code as drivers get converted to the new subsystem.
I'm happy to do the two tsl drivers once the core as discussed in this thread
is in place.

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