linux-stable/include/linux/iio/kfifo_buf.h
Alexandru Ardelean 0a21526bc1 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 5164c78898 ("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>
2021-03-25 19:13:52 +00:00

22 lines
666 B
C

/* SPDX-License-Identifier: GPL-2.0 */
#ifndef __LINUX_IIO_KFIFO_BUF_H__
#define __LINUX_IIO_KFIFO_BUF_H__
struct iio_buffer;
struct iio_buffer_setup_ops;
struct iio_dev;
struct device;
struct iio_buffer *iio_kfifo_allocate(void);
void iio_kfifo_free(struct iio_buffer *r);
int devm_iio_kfifo_buffer_setup_ext(struct device *dev,
struct iio_dev *indio_dev,
int mode_flags,
const struct iio_buffer_setup_ops *setup_ops,
const struct attribute **buffer_attrs);
#define devm_iio_kfifo_buffer_setup(dev, indio_dev, mode_flags, setup_ops) \
devm_iio_kfifo_buffer_setup_ext((dev), (indio_dev), (mode_flags), (setup_ops), NULL)
#endif