tools: iio: iio_generic_buffer ensure alignment

The iio_generic_buffer can return garbage values when the total size of
scan data is not a multiple of the largest element in the scan. This can be
demonstrated by reading a scan, consisting, for example of one 4-byte and
one 2-byte element, where the 4-byte element is first in the buffer.

The IIO generic buffer code does not take into account the last two
padding bytes that are needed to ensure that the 4-byte data for next
scan is correctly aligned.

Add the padding bytes required to align the next sample with the scan size.

Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Fixes: e58537ccce73 ("staging: iio: update example application.")
Link: https://lore.kernel.org/r/ZRvlm4ktNLu+qmlf@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

tools: iio: iio_generic_buffer: Fix some integer type and calculation

In function size_from_channelarray(), the return value 'bytes' is defined
as int type. However, the calcution of 'bytes' in this function is designed
to use the unsigned int type. So it is necessary to change 'bytes' type to
unsigned int to avoid integer overflow.

The size_from_channelarray() is called in main() function, its return value
is directly multipled by 'buf_len' and then used as the malloc() parameter.
The 'buf_len' is completely controllable by user, thus a multiplication
overflow may occur here. This could allocate an unexpected small area.

Signed-off-by: Chenyuan Mi <michenyuan@huawei.com>
Link: https://lore.kernel.org/r/20230725092407.62545-1-michenyuan@huawei.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

tools: iio: iio_generic_buffer: Fix read size

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 <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/Y0kMh0t5qUXJw3nQ@dc75zzyyyyyyyyyyyyycy-3.rev.dnainternet.fi
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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

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 <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20210215104043.91251-25-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

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

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

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

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

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 <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools: iio: iio_generic_buffer: make num_loops signed

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 <mkelly@xevo.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 55dda0abcf9d ("tools: iio: iio_generic_buffer: allow continuous looping")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

tools: iio: iio_generic_buffer: allow continuous looping

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 <mkelly@xevo.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

tools: iio: iio_generic_buffer: fix types to match

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

Signed-off-by: Martin Kelly <mkelly@xevo.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

tools: iio: iio_generic_buffer: drop unneeded parentheses

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

Suggested-by: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

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

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 <pmeerw@pmeerw.net>
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

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

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 <amsfield22@gmail.com>
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

tools: iio: iio_generic_buffer: fix argument '?' option

When help ('?') option is passed to the command, the help text
printed but not from '?' switch case of getopt_long() but as a
invalid argument as below. Fix this by adding '?' to opt_String
of getopt_long().

root@am437x-evm:~# ./iio_generic_buffer -?
./iio_generic_buffer: invalid option -- '?'
Usage: generic_buffer [options]...
Capture, convert and output data from IIO device buffer
-a Auto-activate all available channels
...

Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

tools:iio:iio_generic_buffer: fix trigger-less mode

Passing the trigger-less mode option on the command line causes
iio_generic_buffer to fail searching for an IIO trigger.
Fix this by skipping trigger initialization if trigger-less mode is
requested.

Technically it actually fixes:
7c7e9dad70 where the bug was introduced but as the window to the patch
below that changes the context was very small let's mark it with that.

Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com>
Fixes: deb4d1fdcb5af ("iio: generic_buffer: Fix --trigger-num option")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

tools: iio: iio_generic_buffer: initialize channel array pointer

Uninitialized channel pointer causes segmentation fault when we
call free(channel) during cleanup() with no channels initialized.
This happens when you exit early for usage errors. Initialize
the pointer to NULL when it is declared.

Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Tested-by: Gregor Boirie <gregor.boirie@parrot.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

iio: generic_buffer: Fix --trigger-num option

Initialize trig_num to -1 and handle trig_num=0 as a valid id.

Fixes: 7c7e9dad (iio: iio_generic_buffer: Add --trigger-num option)
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

iio: iio_generic_buffer: Add --trigger-num option

Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

iio: iio_generic_buffer: Add --device-num option

This makes it possible to distinguish between iio devices with the same
name.

Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

iio: iio_generic_buffer: Cleanup when receiving signals

This will clean (disable buffer/trigger/channels) when doing
something like a CTRL-C. Otherwise restarting generic_buffer requires a
manual echo 0 > buffer/enable

This also cleanup up all the code freeing string buffers at
the end of main. We initialize all pointers to NULL so that cleanup can
all be done under a single error label.

Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

tools: iio: Rename generic_buffer to iio_generic_buffer

This makes it clear that generic_buffer is an IIO tool
and also complies with filename conventions in tools/iio.

Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>