linux-kernel - Re: isl29020: ALS driver as misc device

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, 15 Apr 2010 11:09:19 +0100
From:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>
To:	Greg KH <greg@...ah.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Alan Cox <alan@...ux.intel.com>, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: isl29020: ALS driver as misc device

On 04/14/10 18:01, Greg KH wrote:
> On Wed, Apr 14, 2010 at 05:56:02PM +0100, Alan Cox wrote:
>> And this adds the isl29020 as a misc device per discussions
>>
>> isl29020: ambient light sensor
>>
>> From: Kalhan Trisal <kalhan.trisal@...el.com>
>>
>> The LS driver will read the latest Lux measurement based upon the
>> light brightness and will report the LUX output through sysfs interface.
> 
> Please document this sysfs interface with an addition to the
> Documentatin/ABI/ directory.
As documenting this abi (which indeed should be done) is going to set
a precedence, perhaps this is a good time to discuss what this naming could
be.

In cleaning up the IIO abi Greg suggested that we match existing similar
abi's a closely as possible, which where possible makes a great deal of sense
(shared userspace code is possible and it makes everything a bit more predictable
for driver writers... particularly as I expect someone will sooner or later
make a combined hwmon and als chip).

The obvious similarity here is with hwmon.
So perhaps going with naming as

lux-> illuminance0_input  (or I guess lux0_input would also work, I can change
the iio abi to match this as well).

It also occurs to me that we might want to associate the calibration with the
particular channel? There's sure to be a dual ALS chip along at some point.

Obviously the isl29020 would need updating as well.  Everyone was happy to do
that when were writing the ALS subsystem, so I guess that won't have changed!

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/