]> git.baikalelectronics.ru Git - kernel.git/commit
iio: kfifo: add devm_iio_triggered_buffer_setup_ext variant
authorAlexandru Ardelean <aardelean@deviqon.com>
Thu, 11 Mar 2021 09:10:42 +0000 (11:10 +0200)
committerJonathan Cameron <Jonathan.Cameron@huawei.com>
Thu, 25 Mar 2021 19:13:52 +0000 (19:13 +0000)
commitd5637765c34ac5ba63fe5ba330edd05ad18fa6b3
tree2dca4883bc28f57b3f4e33afe08e1b9cc2b1ebdf
parentdf7e005140b1fd962cb0dc62920e282c422c4900
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 f45060b5209c ("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 <aardelean@deviqon.com>
Link: https://lore.kernel.org/r/20210311091042.22417-1-aardelean@deviqon.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
drivers/iio/buffer/kfifo_buf.c
include/linux/iio/kfifo_buf.h