iio: add missing MODULE_DESCRIPTION() macros

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iio/adc/ingenic-adc.o
WARNING: modpost: missing MODU

iio: add missing MODULE_DESCRIPTION() macros

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iio/adc/ingenic-adc.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iio/adc/xilinx-ams.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/iio/buffer/kfifo_buf.o

Add the missing invocations of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: Don't silently expect attribute types

The iio_triggered_buffer_setup_ext() and the
devm_iio_kfifo_buffer_setup_ext() were changed by
commit 15097c7a1adc ("iio: buffer: wrap all buffer attribute

iio: Don't silently expect attribute types

The iio_triggered_buffer_setup_ext() and the
devm_iio_kfifo_buffer_setup_ext() were changed by
commit 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr")
to silently expect that all attributes given in buffer_attrs array are
device-attributes. This expectation was not forced by the API - and some
drivers did register attributes created by IIO_CONST_ATTR().

When using IIO_CONST_ATTRs the added attribute "wrapping" does not copy
the pointer to stored string constant and when the sysfs file is read the
kernel will access to invalid location.

Change the function signatures to expect an array of iio_dev_attrs to
avoid similar errors in the future.

Merge conflict resolved whilst applying due to patch crossing with
two new drivers (kx022a accelerometer and ad4130 ADC).

Signed-off-by: Matti Vaittinen <[email protected]>
Tested-by: Claudiu Beznea <[email protected]>
Link: https://lore.kernel.org/r/63f54787a684eb1232f1c5d275a09c786987fe4a.1664782676.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: core: Simplify the registration of kfifo buffers

Among all the users of the kfifo buffers, no one uses the
INDIO_BUFFER_HARDWARE mode. So let's take this as a general rule and
simplify a little

iio: core: Simplify the registration of kfifo buffers

Among all the users of the kfifo buffers, no one uses the
INDIO_BUFFER_HARDWARE mode. So let's take this as a general rule and
simplify a little bit the internals - overall the documentation - by
eliminating unused specific cases. Use the INDIO_BUFFER_SOFTWARE mode by
default with kfifo buffers, which will basically mimic what all the "non
direct" modes do.

Cc: Benson Leung <[email protected]>
Cc: Guenter Roeck <[email protected]>
Cc: Jyoti Bhayana <[email protected]>
Cc: Jean-Baptiste Maneyrol <[email protected]>
Cc: Lorenzo Bianconi <[email protected]>
Cc: Michael Hennerich <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: kfifo-buffer: Add output buffer support

Add output buffer support to the kfifo buffer implementation.

The implementation is straight forward and mostly just wraps the kfifo
API to provide the

iio: kfifo-buffer: Add output buffer support

Add output buffer support to the kfifo buffer implementation.

The implementation is straight forward and mostly just wraps the kfifo
API to provide the required operations.

Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Alexandru Ardelean <[email protected]>
Signed-off-by: Mihail Chindris <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: kfifo: add devm_iio_triggered_buffer_setup_ext variant

This is similar to the {devm_}iio_triggered_buffer_setup_ext variants added
via commit 5164c7889857 ("iio: triggered-buffer: add
{devm_}ii

iio: kfifo: add devm_iio_triggered_buffer_setup_ext variant

This is similar to the {devm_}iio_triggered_buffer_setup_ext variants added
via commit 5164c7889857 ("iio: triggered-buffer: add
{devm_}iio_triggered_buffer_setup_ext variants").

These can be used to pass extra buffer attributes to the buffer object.
This is a bit of temporary mechanism (hopefully) so that drivers that want
to allocate a kfifo buffer with extra buffer attributes, don't need to
include 'buffer_impl.h' directly. This can also become an API function (in
it's own right, unfortunately), but it may be a little less bad vs drivers
having to include 'buffer_impl.h'.

So, far the drivers that want to pass buffer attributes, all have to do
with some HW FIFO attributes, so there may be a chance of unifying them
into IIO core somehow (as some standard API). But, until that happens, we
just need to let them register their HW FIFO attributes directly (without
having to let them include 'buffer_impl.h' directly).

Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: buffer: kfifo_buf: kernel-doc, typo in function name.

Should have been _kfifo_ and was _fifo_

Signed-off-by: Jonathan Cameron <[email protected]>
Acked-by: Alexandru Ardelean <ardele

iio: buffer: kfifo_buf: kernel-doc, typo in function name.

Should have been _kfifo_ and was _fifo_

Signed-off-by: Jonathan Cameron <[email protected]>
Acked-by: Alexandru Ardelean <[email protected]>
Reviewed-by: Lars-Peter Clausen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

iio: kfifo: mask flags without zero-check in devm_iio_kfifo_buffer_setup()

As pointed by Lars, this doesn't require a zero-check. Also, while looking
at this a little closer at it (again), the maski

iio: kfifo: mask flags without zero-check in devm_iio_kfifo_buffer_setup()

As pointed by Lars, this doesn't require a zero-check. Also, while looking
at this a little closer at it (again), the masking can be done later, as
there is a zero-check for 'mode_flags' anyway, which returns -EINVAL. And
we only need the 'mode_flags' later in the logic.

This change is more of a tweak.

Fixes: e36db6a06937 ("iio: kfifo: add devm_iio_kfifo_buffer_setup() helper")
Cc: Lars-Peter Clausen <[email protected]>
Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: buffer: introduce support for attaching more IIO buffers

With this change, calling iio_device_attach_buffer() will actually attach
more buffers.
Right now this doesn't do any validation of whet

iio: buffer: introduce support for attaching more IIO buffers

With this change, calling iio_device_attach_buffer() will actually attach
more buffers.
Right now this doesn't do any validation of whether a buffer is attached
twice; maybe that can be added later (if needed). Attaching a buffer more
than once should yield noticeably bad results.

The first buffer is the legacy buffer, so a reference is kept to it.

At this point, accessing the data for the extra buffers (that are added
after the first one) isn't possible yet.

The iio_device_attach_buffer() is also changed to return an error code,
which for now is -ENOMEM if the array could not be realloc-ed for more
buffers.
To adapt to this new change iio_device_attach_buffer() is called last in
all place where it's called. The realloc failure is a bit difficult to
handle during un-managed calls when unwinding, so it's better to have this
as the last error in the setup_buffer calls.

At this point, no driver should call iio_device_attach_buffer() directly,
it should call one of the {devm_}iio_triggered_buffer_setup() or
devm_iio_kfifo_buffer_setup() or devm_iio_dmaengine_buffer_setup()
functions. This makes iio_device_attach_buffer() a bit easier to handle.

Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: kfifo: un-export devm_iio_kfifo_allocate() function

At this point all drivers should use devm_iio_kfifo_buffer_setup() instead
of manually allocating via devm_iio_kfifo_allocate() and assigning

iio: kfifo: un-export devm_iio_kfifo_allocate() function

At this point all drivers should use devm_iio_kfifo_buffer_setup() instead
of manually allocating via devm_iio_kfifo_allocate() and assigning ops and
modes.

With this change, the devm_iio_kfifo_allocate() will be made private to the
IIO core, since all drivers should call either
devm_iio_kfifo_buffer_setup() or devm_iio_triggered_buffer_setup() to
create a kfifo buffer.

Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: kfifo: add devm_iio_kfifo_buffer_setup() helper

This change adds the devm_iio_kfifo_buffer_setup() helper/short-hand,
which groups the simple routine of allocating a kfifo buffers via
devm_iio_

iio: kfifo: add devm_iio_kfifo_buffer_setup() helper

This change adds the devm_iio_kfifo_buffer_setup() helper/short-hand,
which groups the simple routine of allocating a kfifo buffers via
devm_iio_kfifo_allocate() and calling iio_device_attach_buffer().

The mode_flags parameter is required, as the IIO kfifo supports 2 modes:
INDIO_BUFFER_SOFTWARE & INDIO_BUFFER_TRIGGERED.
The setup_ops parameter is optional.

This function will be a bit more useful when needing to define multiple
buffers per IIO device.

The naming for this function has been inspired from
iio_triggered_buffer_setup() since that one does a kfifo alloc + a pollfunc
alloc. So, this should have a more familiar ring to what it is.

Signed-off-by: Alexandru Ardelean <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: buffer: drop devm_iio_kfifo_free() API call

It's unused so far, so it can be removed. Also makes sense to remove it
to discourage weird uses of this call during review.

Signed-off-by: Alexandr

iio: buffer: drop devm_iio_kfifo_free() API call

It's unused so far, so it can be removed. Also makes sense to remove it
to discourage weird uses of this call during review.

Signed-off-by: Alexandru Ardelean <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio: buffer: rename 'read_first_n' callback to 'read'

It is implied that 'read' will read the first n bytes and not e.g. bytes
only from offsets within the buffer that are a prime number.

This chan

iio: buffer: rename 'read_first_n' callback to 'read'

It is implied that 'read' will read the first n bytes and not e.g. bytes
only from offsets within the buffer that are a prime number.

This change is non-functional, mostly just a rename.
A secondary intent with this patch is to make room later to add a write
callback.

Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Alexandru Ardelean <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

treewide: Add SPDX license identifier for more missed files

Add SPDX license identifiers to all files which:

- Have no license information of any form

- Have MODULE_LICENCE("GPL*") inside which

treewide: Add SPDX license identifier for more missed files

Add SPDX license identifiers to all files which:

- Have no license information of any form

- Have MODULE_LICENCE("GPL*") inside which was used in the initial
scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

GPL-2.0-only

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

iio:kfifo_buf: check for uint overflow

Currently, the following causes a kernel OOPS in memcpy:

echo 1073741825 > buffer/length
echo 1 > buffer/enable

Note that using 1073741824 instead of 1073741

iio:kfifo_buf: check for uint overflow

Currently, the following causes a kernel OOPS in memcpy:

echo 1073741825 > buffer/length
echo 1 > buffer/enable

Note that using 1073741824 instead of 1073741825 causes "write error:
Cannot allocate memory" but no OOPS.

This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo
rounds up to the nearest power of 2, it will actually call kmalloc with
roundup_pow_of_two(length) * bytes_per_datum.

Using length == 1073741825 and bytes_per_datum == 2, we get:

kmalloc(roundup_pow_of_two(1073741825) * 2
or kmalloc(2147483648 * 2)
or kmalloc(4294967296)
or kmalloc(UINT_MAX + 1)

so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and
subsequent memcpy to fail once the device is enabled.

Fix this by checking for overflow prior to allocating a kfifo. With this
check added, the above code returns -EINVAL when enabling the buffer,
rather than causing an OOPS.

Signed-off-by: Martin Kelly <[email protected]>
cc: <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio:buffer: make length types match kfifo types

Currently, we use int for buffer length and bytes_per_datum. However,
kfifo uses unsigned int for length and size_t for element size. We need
to make

iio:buffer: make length types match kfifo types

Currently, we use int for buffer length and bytes_per_datum. However,
kfifo uses unsigned int for length and size_t for element size. We need
to make sure these matches or we will have bugs related to overflow (in
the range between INT_MAX and UINT_MAX for length, for example).

In addition, set_bytes_per_datum uses size_t while bytes_per_datum is an
int, which would cause bugs for large values of bytes_per_datum.

Change buffer length to use unsigned int and bytes_per_datum to use
size_t.

Signed-off-by: Martin Kelly <[email protected]>
Cc: <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

iio:buffer.h - split into buffer.h and buffer_impl.h

buffer.h supplies everything needed for devices using buffers.
buffer_impl.h supplies access to the internals as needed to write
a buffer impleme

iio:buffer.h - split into buffer.h and buffer_impl.h

buffer.h supplies everything needed for devices using buffers.
buffer_impl.h supplies access to the internals as needed to write
a buffer implementation.

This was really motivated by the mess that turned up in the
kernel-doc documentation pulled in by the new sphinx docs.
It made it clear that our logical separations in headers were
generally terrible. The buffer case was easy to sort out without
greatly effecting drivers so here it is.

Signed-off-by: Jonathan Cameron <[email protected]>
Reviewed-by: Lars-Peter Clausen <[email protected]>

show more ...

iio:buffer.h include pushdown into buffer implementations

These were only getting access to the internals of struct iio_dev via
the include of iio.h within buffer.h. This should always have been
ex

iio:buffer.h include pushdown into buffer implementations

These were only getting access to the internals of struct iio_dev via
the include of iio.h within buffer.h. This should always have been
explicitly included by the buffer implementations themselves.

Signed-off-by: Jonathan Cameron <[email protected]>
Reviewed-by: Lars-Peter Clausen <[email protected]>

show more ...

iio:kfifo_buf header include push down.

As a precursor to splitting buffer.h, lets make sure all drivers
include the relevant headers rather than relying on picking them
up from kfifo_buf.h.

Signed

iio:kfifo_buf header include push down.

As a precursor to splitting buffer.h, lets make sure all drivers
include the relevant headers rather than relying on picking them
up from kfifo_buf.h.

Signed-off-by: Jonathan Cameron <[email protected]>
Reviewed-by: Lars-Peter Clausen <[email protected]>

show more ...

iio: Move generic buffer implementations to sub-directory

For generic IIO trigger implementations we already have a sub-directory,
but the generic buffer implementations currently reside in the IIO

iio: Move generic buffer implementations to sub-directory

For generic IIO trigger implementations we already have a sub-directory,
but the generic buffer implementations currently reside in the IIO
top-level directory. The main reason is that things have historically grown
into this form.

With more generic buffer implementations on its way now is the perfect time
to clean this up and introduce a sub-directory for generic buffer
implementations to avoid too much clutter in the top-level directory.

Signed-off-by: Lars-Peter Clausen <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...