Here I've kept the selection of IIO_SW_RING separate from
IIO_TRIGGER as it will go away fairly shortly when the ring buffer
type becomes configurable on a per device basis, whereas the
IIO_TRIGGER select will remain. Whether to retain the option to
remove the support for ring buffers entirely is one for after that
support is in place.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Both the max1363 and lis3l02dq modules rely on IIO trigger support in
their ring buffer implementations, which is presently a separate config
option. In the case of IIO_RING_BUFFER=y and IIO_TRIGGER=n, we end up
with the following:
ERROR: "iio_trigger_attach_poll_func" [drivers/staging/iio/adc/max1363.ko] undefined!
ERROR: "iio_trigger_dettach_poll_func" [drivers/staging/iio/adc/max1363.ko] undefined!
ERROR: "iio_trigger_unregister" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_trigger_notify_done" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_trigger_read_name" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_trigger_poll" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_trigger_attach_poll_func" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_trigger_register" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_free_trigger" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_trigger_dettach_poll_func" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
ERROR: "iio_allocate_trigger" [drivers/staging/iio/accel/lis3l02dq.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
This adds an IIO_TRIGGER select for these two drivers conditional on
IIO ring buffer support. Caught with an SH randconfig in -next.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Error handling code following a kmalloc or kzalloc should free the
allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
device attr's should be static, otherwise duplicate identifiers are
created:
drivers/staging/iio/trigger/iio-trig-gpio.o:(.data+0x1c): multiple definition of `dev_attr_name'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Example of relatively common case of device sampling
based on internal clock and providing a data ready
signal to indicate that new data is available to be
read out.
Generic trigger approach used to allow other devices
to be sampled 'at the same time' as this the accelerometer.
This is very useful in various motion estimation algorithms.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Example of how a device with a hardware ring buffer is
handled within IIO.
Changes since V2:
* Moved to new registration functions giving much cleaner
interface.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This provides only very minimal support for this device.
Note that an alternate driver has been posted to the input
mailing list.
When the original LMKL discussion that led to the descision
to develop IIO occured, the question on whether the differing
requirements of IIO and input drivers made it a good idea
to have unified drivers was left as an open question.
It still is. All opinions on this question welcome.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A later patch in the series will add data ready triggering
and ring buffer support.
This core patch provides an event interface and sysfs
based reading of values.
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
