linux-kernel - Re: Accelerometer, Gyros and ADC's etc within the kernel.

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:	Tue, 20 May 2008 23:40:06 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Jonathan Cameron <Jonathan.Cameron@...il.com>,
	linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net,
	LM Sensors <lm-sensors@...sensors.org>,
	Dmitry Torokhov <dtor@...l.ru>
Subject: Re: Accelerometer, Gyros and ADC's etc within the kernel.

On Tue, May 20, 2008 at 01:28:17PM +0200, Jean Delvare wrote:
> Hi Jonathan,
> 
> On Tue, 20 May 2008 11:04:01 +0100, Jonathan Cameron wrote:
> > This email is basically a request for opinions on how and where such sensors
> > should be integrated into the kernel.
> > 
> > To set the scene...
> > 
> > Increasing numbers of embedded devices are being supplied attached MEMS
> > devices (www.xbow.com imote2 etc). Along with more traditional sensors such
> > as ADC's not being used for hardware monitoring, these do not really 
> > seem to
> > fit with in an particular subsystem of the kernel.  A previous 
> > discussion on
> > lkml in 2006 considered the accelerometers to be found within some laptop
> > hard drives, but I haven't been able to track down any more general 
> > discussions
> > of such non hardware monitoring sensors.
> > 
> > The obvious possibilities are:
> > 
> > * To place the various drivers within the spi / i2c etc subsystems as 
> > relevant.
> 
> Bad idea. Grouping drivers by connectivity is almost always the wrong
> thing to do, as it means that different persons will maintain them and
> they have all chances to diverge. You really want to group drivers by
> functionality. On top of that, I am busy enough maintaining the i2c
> core and bus drivers without having more i2c device drivers added to my
> plate. These days I am trying to _empty_ drivers/i2c/chips, if anything.

100% ACK. And the functionality here is something like "industrial
control" or "automation I/O". If this sort of hardware appears as device
with mappable memory, we can handle it with UIO, but for SPI, I2C, USB,
serial, we should have a new subsystem. It should handle not only input,
but also similar output devices. It doesn't make sense to have ADCs in
one subsystem, and DACs in a different one.

> 
> > * To place within the hwmon subsystem as this is probably closest.
> > (there is already at least one straight ADC driver in hwmon)
> 
> Probably not the wisest choice, if nothing else, because the hwmon
> maintainer is already overloaded. And I don't think that these devices
> have much in common with the traditional hardware monitoring components
> anyway.

Agreed, hwmon devices are not really tuned for maximum performance, for
example. Performance is often critical in automation control
applications.

> 
> I'm not sure what "straight ADC driver" you are referring to, but
> anything which measures a voltage and exports the reading to user-space
> is, well, a voltage sensor, and thus fix within hwmon. If the same chip
> is used for a higher-level, dedicated function then we would probably
> have a separate driver for it, outside of hwmon.
> 
> > * To create a new subsystem, or perhaps merely sysfs class to contain these
> >   elements.
> 
> Would be OK.

Definitely.

> Or:
> 
> * Place these within the input subsystem. You might want to discuss
> this with the input subsystem maintainer Dmitry Torokhov (Cc'd). The
> Wii remote is essentially a joystick, and joysticks belong to the input
> subsystem.

This might apply to some devices, but not all. And the requirements are
quite different, I think.

> 
> This all sounds quite different from our hwmon drivers. Our hwmon
> drivers read all the sensor values at once and cache the readings for a
> couple seconds, so you can't get an instant reading at any time, and
> they also don't support interrupts in general.

Exactly.

Thanks,
Hans

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