linux-kernel - Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc)

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:	Wed, 23 Jul 2008 20:33:34 +0100
From:	Ben Dooks <ben-linux@...ff.org>
To:	Jonathan Cameron <Jonathan.Cameron@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	spi-devel-general@...ts.sourceforge.net,
	LM Sensors <lm-sensors@...sensors.org>, mgross@...ux.intel.com,
	Dmitry Torokhov <dtor@...l.ru>,
	David Brownell <david-b@...bell.net>, hmh@....eng.br,
	Jean Delvare <khali@...ux-fr.org>,
	Ben Nizette <bn@...sdigital.com>
Subject: Re: [spi-devel-general] [Patch 0/4] IndustrialIO subsystem (ADCs, accelerometers etc)

On Wed, Jul 23, 2008 at 06:00:29PM +0100, Jonathan Cameron wrote:
> 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.

Thinking about this, basically we have an event buffer and management
system that could live in  drivers/event. It manages the event sources
and buffering, including tagging the data and buffering it ready for
consumption.

One thing I'd like to see is that the reading application should be
able to choose to have events aggregated or not, so that if a few
events turn up very fast it can choose to take them as one single
item.
 
> 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)

Having an update rate and buffering is possibly useful, given that if you
have say a number of ADC inputs but only one converter, then it is possible
that there will be some form of resource starvation.
 
> * 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.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

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