linux-kernel - Re: LIS331DLH accelerometer driver, IIO or not?

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: <4FC19C0B.8080809@linux.intel.com>
Date:	Sat, 26 May 2012 20:14:19 -0700
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Jonathan Cameron <jic23@....ac.uk>
CC:	Éric Piel <eric.piel@...mplin-utc.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"lkml, " <linux-kernel@...r.kernel.org>,
	Jonathan Cameron <jic23@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Carmine Iascone <carmine.iascone@...com>,
	Matteo Dameno <matteo.dameno@...com>
Subject: Re: LIS331DLH accelerometer driver, IIO or not?



On 05/26/2012 10:40 AM, Jonathan Cameron wrote:
> On 05/26/2012 12:53 PM, Éric Piel wrote:
>> On 25-05-12 07:10, Greg Kroah-Hartman wrote:
>>> On Thu, May 24, 2012 at 09:29:53PM -0700, Darren Hart wrote:
>>>> I'm working to enable the LIS331DLH accelerometer on the Fish River
>>>> Island II embedded atom development kit.
>>>>
>>>> I am more interested in enabling people to do bizarre and interesting
>>>> things with the device, so I'm leaning toward continuing with my IIO
>>>> implementation.
>>>
>>> Make it an IIO driver and then we can delete the misc driver, which
>>> shouldn't have snuck in there in the first place :)
>>>
>>
>> To be more fair to the misc driver, I wouldn't say it snucked in there,
>> but more "it ended up there as the least worse place" ;-) Actually, the
>> main problem is that there seemed to be no maintainer interested in
>> taking care of accelerometer devices. Now that the IIO subsystem is out
>> of staging, it might be a right place. That said, I don't know much
>> about the user interface to IIO. I know that I liked the idea of having
>> an joystick device created for an accelerometer because that allows to
>> get many programs to access the device almost without any modifications.
> I agree that this sort of device should have an input interface. Not
> sure if a joystick is the right option, but that's more one for Dmitry
> to comment on.
>>
>> I'd happy to help merge the lis3lv02d driver into IIO. IMHO, the main
>> steps are:
>>  * make sure all the various buses are supported (e.g., I²C, SPI, and
>> also "ACPI-HP")
>>  * ensure the various versions of the accelerometer are supported (there
>> are 3 supported currently)
>>  * check that the driver is automatically loaded on HP laptops (via ACPI
>> entry)
>>  * for each of the current interfaces decide if they should be ported or
>> dropped (/dev/js*, /dev/freefall, sysfs...)
>>
>> What do you think Jonathan?
> You've laid it out extremely clearly.  Thanks, I agree with these steps,
> though they may occur from a slightly different angle given Darren is
> interested in a part that is not (I believe) currently supported by
> your existing driver.   Hence he may initially want to do a separate
> driver with that (keeping in mind the aim of mergining in the existing
> driver).  I have an ancient driver for the lis3l02dq alone (in
> iio from the start) that will also get eaten up by Daren's new driver
> (and the ability to test on that part on spi).
> staging/iio/accel/lis3l02dq*.c

I think I should start with getting the lis331dlh support completed, if
for no other reason than to keep the scope manageable as I write my
first real driver. From that I would like to merge in Jonathan's IIO
lis3l02dq driver to get the multi-chip support part right. Then we
should look at expanding the scope of the interface and finally merging
with misc/lis3102dq. I believe that should meet with everyone's suggestions.

One thing I would like to understand better is what sort of interface
does userspace current expect. Phone Gap, for example, provides a very
high level interface to applications in m/s^2 for each axis. Is there
some interface we should ensure all accelerometer driver's implement?

I suspect a /dev/accel interface that reads out xyz values in ms/s^2
would make sense. We would need to ensure that allows for polled as well
as event driven. Thoughts?


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
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/