linux-kernel - Re: [PATCH 2/4] misc: add LM3533 ambient light sensor driver

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, 26 Apr 2012 13:52:00 +0200
From:	Johan Hovold <jhovold@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Richard Purdie <rpurdie@...ys.net>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Arnd Bergmann <arnd@...db.de>,
	Florian Tobias Schandinat <FlorianSchandinat@....de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-fbdev@...r.kernel.org
Subject: Re: [PATCH 2/4] misc: add LM3533 ambient light sensor driver

On Fri, Apr 20, 2012 at 10:37:54AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Apr 20, 2012 at 07:28:49PM +0200, Johan Hovold wrote:
> > On Fri, Apr 20, 2012 at 08:57:34AM -0700, Greg Kroah-Hartman wrote:
> > > On Fri, Apr 20, 2012 at 05:30:24PM +0200, Johan Hovold wrote:
> > > > Add sub-driver for the ambient light sensor in National Semiconductor /
> > > > TI LM3533 lighting power chips.
> > > > 
> > > > Raw ADC values as well as current ALS zone can be retrieved through
> > > > sysfs. The ALS zone can also be read using a character device
> > > > (/dev/lm3533-als) which is updated on zone changes (interrupt driven or
> > > > polled).
> > > > 
> > > > The driver provides a configuration interface through sysfs.
> > > 
> > > Which seems to not be documented at all :(
> > 
> > There are the following sysfs entries for configuring ALS control:
> 
> <snip>
> 
> That's fine, but you need a Documentation/ABI entry for any new sysfs
> file you create.
> > > What about using the iio interface for this instead?  Doesn't that
> > > already provide this standard interface you are looking for?
> > 
> > I had a look at iio last fall and decided not to use it at the time. I
> > can't remember exactly what the reasons were right now, so I'll have
> > to get back to you on this.
> 
> Please look into this, the iio framework is about to move out of the
> staging tree for 3.5, so there should not be any reason for you to
> create yet-another user api for this type of thing.

We had an initial requirement to support fairly old kernels, but this
have since been relaxed (and has of course never in itself been a valid
reason to not use iio for upstream). As iio is moving out of staging, I
see no problems using it, and the required changes appear quite small.

I'll submit a v2 against iio and make sure to document the sysfs-entries.

Thanks,
Johan
--
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/