linux-kernel - Re: [PATCH] LIS3LV02Dx Accelerometer driver (take 4)

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: <48FBBDB7.50305@tremplin-utc.net>
Date:	Mon, 20 Oct 2008 01:07:35 +0200
From:	Eric Piel <eric.piel@...mplin-utc.net>
To:	Jonathan Cameron <Jonathan.Cameron@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@...e.cz>,
	Yan Burman <burman.yan@...il.com>,
	Pau Oliva Fora <pau@...ack.org>
Subject: Re: [PATCH] LIS3LV02Dx Accelerometer driver (take 4)

Jonathan Cameron schreef:
> Hi Eric,
> 
> Nice looking driver. 
>> * Several people suggested to not put it in hwmon but in the future industrialio susbsystem: fine with that but as the industrialio subsystem is not available yet, it's still in hwmon with the other accelerometer drivers for now, and I'll happily move it whenever industrialio is integrated.
>>   
> Hmm.. might be a little while yet and there's still the debate on whether
> support for input subsystem is a good idea (different requirements etc).
> I'd be inclined to have a driver for this accelerometer in there, but the
> form it may be somewhat  different (for example, that datardy signal
> is vital in the sort of apps iio is designed for!)
> 
> Also, looking at the code, I'm not sure how similar things are to the
> equivalent i2c or spi interfaces.  Guess that'll only become entirely
> clear on implementation.
I'm hopeful it will be rather similar, but time will be judge ;-) I
believe the main difference in the driver requirement might not so much
come from the interface, but from the original reason someone put an
accelerometer in the system. It's in the laptops in order to detect
free-fall (for harddisk protection). It's in a phone in order to rotate
the screen when the phone is rotated. It's in the arm of a robot in
order to provide feedback on the motors. There are guys who just want to
use it to play neverball on their laptop. A generic accelerometer
subsystem will have to provide interfaces to comply to all the needs of
the usages, and should abstract the fact that several interfaces are
present from the driver.

> 
> I'll try and get an updated version of industrialio patches as is out later
> this week.
Great!

>> +Sysfs attributes under /sys/devices/platform/lis3lv02d/:
>> +position - 3D position that the accelerometer reports. Format: "(x,y,z)"
>>   
> Hmm. Position? I've probably missed the debate on why it is called
> this.... 
Hehe, probably there has been no debate. I'm using the de-facto standard
defined by the hdaps driver. You can consider this as another incentive
to propose an official accelerometer subsystem ;-)


>> +/*
>> + * The sensor can also generate interrupts (DRDY) but it's pretty pointless
>> + * because their are generated even if the data do not change.
> Unless there is some serious filtering the noise level on such a chip
> will mean
> it almost always changes anyway.  However, for this type of app I can
> see your
> point!
Actually, when you leave the laptop without touching it in a calm
environment, the movement is very little and the detected changes are
around 1Hz. Anyway, the absolute reason that you cannot use the DRDY
interrupt is that if you use it, the free-fall and direction detection
are not usable anymore (interrupt cannot be shared).

See you,
Eric
--
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/