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-next>] [day] [month] [year] [list]
Date:	Wed, 23 Jul 2008 18:00:29 +0100
From:	Jonathan Cameron <Jonathan.Cameron@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>,
	spi-devel-general@...ts.sourceforge.net,
	LM Sensors <lm-sensors@...sensors.org>
CC:	Jean Delvare <khali@...ux-fr.org>, Dmitry Torokhov <dtor@...l.ru>,
	"Hans J. Koch" <hjk@...utronix.de>, hmh@....eng.br,
	David Brownell <david-b@...bell.net>, mgross@...ux.intel.com,
	Ben Nizette <bn@...sdigital.com>,
	Anton Vorontsov <avorontsov@...mvista.com>
Subject: [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc)

Dear All,

The need for an industrialio subsystem was discussed in
http://lkml.org/lkml/2008/5/20/135

Firstly thanks to all the people who have contributed to the discussion
of this in the past.

In brief the intention is provide a kernel subsystem directed towards the
handling on sensors (and later related output devices) such as ADC's,
accelerometers and many others.

Key features of the subsystem include:

* Provision of sysfs access for direct reading from devices (similar to hwmon
  but without the buffering / update rate restrictions)

* Provision of chrdevs through which events may be passed to userspace in a
  similar fashion to the input subsystem.  These events may be anything from
  hardware thresholds set on the sensor itself to sw / hw ring buffer event
  notifications (50% full etc).

* Provision of access via chrdevs to hardware ring buffers on devices that
  provide them.

* Software ring buffer support to allow semi regular capture of data form the
  device.  Typically this will be driven from either datardy events, or from
  a periodic timer interrupt (to this end a very simple wrapper for periodic
  RTC's is included. This will move to more generic timer interfaces as and when
  they become available.  For now available rtc's must be registered with the
  subsystem via the industrialio_register_ptimer function form within a board
  init.

* A set of sample drivers illustrating the main 'classes' of device. By classes
  I really mean devices that are interfaced with in a similar way.

The subsystem is now in a functional state with a small set of drivers:

Max1363 (supports numerous Maxim i2c ADC's) (tested with max1363 and max1238 chips)
   - Uses a periodic timer to provide ring buffer mode.
   - All reads form these devices are scan modes so direct single element access
     is not provided.
   - Monitor mode on max1363 is not yet supported (need to do a bit debugging of
     the board I have so as to be able to test this).

ST LIS3L02DQ - SPI accelerometer.
   - Uses a datardy interrupt to driver a software ring buffer.
   - Most functionality of this device is supported.

VTI SCA3000 (tested with an e05)
   - Hardware ring buffer.

More drivers in preparation.

Next focus will be on cleaning up / implementing a more generic timer framework
and allowing the system to partly run if not all dependencies are met 
(particularly availability of timers).

An initial set of patches will be attached to this thread shortly.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ