linux-toradex.git/tools/iio/iio_generic_buffer.c, branch v6.3

tools: iio: iio_generic_buffer: Fix read size

2022-11-01T08:48:13+00:00

When noevents is true and small buffer is used the allocated memory for
holding the data may be smaller than the hard-coded 64 bytes. This can
cause the iio_generic_buffer to crash.

Following was recorded on beagle bone black with v6.0 kernel and the
digit fix patch:
https://lore.kernel.org/all/Y0f+tKCz+ZAIoroQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi/
using valgrind;

==339== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==339== Command: /iio_generic_buffer -n kx022-accel -T0 -e -l 10 -a -w 2000000
==339== Parent PID: 307
==339==
==339== Syscall param read(buf) points to unaddressable byte(s)
==339==    at 0x496BFA4: read (read.c:26)
==339==    by 0x11699: main (iio_generic_buffer.c:724)
==339==  Address 0x4ab3518 is 0 bytes after a block of size 160 alloc'd
==339==    at 0x4864B70: malloc (vg_replace_malloc.c:381)
==339==    by 0x115BB: main (iio_generic_buffer.c:677)

Fix this by always using the same size for reading as was used for
data storage allocation.

Signed-off-by: Matti Vaittinen 
Link: https://lore.kernel.org/r/Y0kMh0t5qUXJw3nQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi
Signed-off-by: Jonathan Cameron

tools: iio: convert iio_generic_buffer to use new IIO buffer API

2021-03-11T20:47:07+00:00

This change makes use of the new IIO buffer API to read data from an IIO
buffer.
It doesn't read the /sys/bus/iio/devices/iio:deviceX/scan_elements dir
anymore, it reads /sys/bus/iio/devices/iio:deviceX/bufferY, where all the
scan_elements have been merged together with the old/classical buffer
attributes.

And it makes use of the new IIO_BUFFER_GET_FD_IOCTL ioctl to get an FD for
the IIO buffer for which to read data from.
It also does a quick sanity check to see that -EBUSY is returned if reading
the chardev after the ioctl() has succeeded.

This was tested with the following cases:
 1. Tested buffer0 works with ioctl()
 2. Tested that buffer0 can't be opened via /dev/iio:deviceX after ioctl()
    This check should be omitted under normal operation; it's being done
    here to check that the driver change is sane
 3. Moved valid buffer0 to be buffer1, and tested that data comes from it

Signed-off-by: Alexandru Ardelean 
Link: https://lore.kernel.org/r/20210215104043.91251-25-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron

tools: iio: privatize globals and functions in iio_generic_buffer.c file

2021-03-11T20:47:06+00:00

Mostly a tidy-up.
But also helps to understand the limits of scope of these functions and
globals.

Signed-off-by: Alexandru Ardelean 
Link: https://lore.kernel.org/r/20210215104043.91251-24-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman

tools: iio: iio_generic_buffer: make num_loops signed

2019-01-12T18:17:56+00:00

Currently, num_loops is unsigned, but it's set by strtoll, which returns a
(signed) long long int. This could lead to overflow, and it also makes the
check "num_loops < 0" always be false, since num_loops is unsigned.
Setting num_loops to -1 to loop forever is almost working because num_loops
is getting set to a very high number, but it's technically still incorrect.

Fix this issue by making num_loops signed. This also fixes an error found
by Smatch.

Signed-off-by: Martin Kelly 
Reported-by: Dan Carpenter 
Fixes: 55dda0abcf9d ("tools: iio: iio_generic_buffer: allow continuous looping")
Cc: 
Signed-off-by: Jonathan Cameron

tools: iio: iio_generic_buffer: allow continuous looping

2018-05-20T13:55:58+00:00

Sometimes it's useful to stream samples forever, such as when
stress-testing a driver overnight to check for memory leaks or other
issues. When the program receives a signal, it will gracefully cleanup,
so it is still safe to terminate at any time.

Add support for specifying a negative -c option, meaning that we should
loop forever. To do so, we need to use a long long (instead of just
long) for num_loops so that current code specifying num_loops greater
than UNSIGNED_LONG_MAX doesn't break.

Signed-off-by: Martin Kelly 
Signed-off-by: Jonathan Cameron

tools: iio: iio_generic_buffer: fix types to match

2018-05-20T13:54:39+00:00

Several types are mismatched and causing implicit conversions.  Fix them
up so the types match.

Signed-off-by: Martin Kelly 
Signed-off-by: Jonathan Cameron

tools: iio: iio_generic_buffer: drop unneeded parentheses

2016-10-23T18:34:10+00:00

Remove extra parentheses introduced in commit <73e176a tools: iio:
iio_generic_buffer: add -A to force-enable all channels>.

Suggested-by: Peter Meerwald-Stadler 
Signed-off-by: Eva Rachel Retuya 
Signed-off-by: Jonathan Cameron

tools: iio: iio_generic_buffer: rename and change type of force variable

2016-10-23T18:34:10+00:00

Replace the type of 'force' flag from int to bool and at the same time
rename it to 'force_autochannels' for better readability.

Suggested-by: Peter Meerwald-Stadler 
Signed-off-by: Eva Rachel Retuya 
Signed-off-by: Jonathan Cameron

tools: iio: iio_generic_buffer: add -A to force-enable all channels

2016-10-23T18:33:53+00:00

If attribute/s is/are already enabled (by default or via scripts or
manual interaction), issuing -a will fail to enable the channels thereby
one has to manually disable the said attribute/s before proceeding with
auto-enabling.

Add a command-line option -A to force-activate all channels regardless
of their current state.

Suggested-by: Alison Schofield 
Signed-off-by: Eva Rachel Retuya 
Signed-off-by: Jonathan Cameron