summaryrefslogtreecommitdiff
path: root/include/linux/iio/common
diff options
context:
space:
mode:
authorAlexandru Ardelean <aardelean@deviqon.com>2021-03-11 12:10:42 +0300
committerJonathan Cameron <Jonathan.Cameron@huawei.com>2021-03-25 22:13:52 +0300
commit0a21526bc1d41456f1b320cce35c9c66238fb1c9 (patch)
tree2dca4883bc28f57b3f4e33afe08e1b9cc2b1ebdf /include/linux/iio/common
parente1d392dc8875556d8a742d4be38ab452516428eb (diff)
downloadlinux-0a21526bc1d41456f1b320cce35c9c66238fb1c9.tar.xz
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 <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210311091042.22417-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Diffstat (limited to 'include/linux/iio/common')
0 files changed, 0 insertions, 0 deletions