kernel/linux.git/drivers/iio/buffer, branch v5.15.210

iio: buffer: hw-consumer: fix use-after-free in error path

2026-06-19T11:33:27+00:00

commit 6f5ed4f2c7c83f33344e0ba179f72a12e5dad4a4 upstream. In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code was using list_for_each_entry() to iterate through buffers while calling iio_buffer_put() which can free the current buffer if refcount drops to 0. The list_for_each_entry() loop macro then evaluates buf->head.next to continue iteration, accessing the freed buffer. Fix this by using list_for_each_entry_safe(). Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support") Reported-by: sashiko Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com Signed-off-by: Felix Gu Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Reviewed-by: Maxwell Doose Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: buffer-dmaengine: fix releasing dma channel on error

2024-09-12T09:07:50+00:00

commit 84c65d8008764a8fb4e627ff02de01ec4245f2c4 upstream. If dma_get_slave_caps() fails, we need to release the dma channel before returning an error to avoid leaking the channel. Fixes: 2d6ca60f3284 ("iio: Add a DMAengine framework based buffer") Signed-off-by: David Lechner Link: https://patch.msgid.link/20240723-iio-fix-dmaengine-free-on-error-v1-1-2c7cbc9b92ff@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: triggered-buffer: prevent possible freeing of wrong buffer

2024-01-05T14:13:32+00:00

commit bce61476dc82f114e24e9c2e11fb064781ec563c upstream. Commit ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") introduced support for multiple buffers per indio_dev but left indio_dev->buffer for a few legacy use cases. In the case of the triggered buffer, iio_triggered_buffer_cleanup() still assumes that indio_dev->buffer points to the buffer allocated by iio_triggered_buffer_setup_ext(). However, since iio_triggered_buffer_setup_ext() now calls iio_device_attach_buffer() to attach the buffer, indio_dev->buffer will only point to the buffer allocated by iio_device_attach_buffer() if it the first buffer attached. This adds a check to make sure that no other buffer has been attached yet to ensure that indio_dev->buffer will be assigned when iio_device_attach_buffer() is called. As per discussion in the review thread, we may want to deal with multiple triggers per device, but this is a fix for the issue in the meantime and any such support would be unlikely to be suitable for a backport. Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") Signed-off-by: David Lechner Acked-by: Nuno Sa Link: https://lore.kernel.org/r/20231031210521.1661552-1-dlechner@baylibre.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: core: move @id from struct iio_dev to struct iio_dev_opaque

2021-05-17T12:49:13+00:00

Continuing from Alexandru Ardelean's introduction of the split between driver modifiable fields and those that should only be set by the core. This could have been done in two steps to make the actual move after introducing iio_device_id() but there seemed limited point to that given how mechanical the majority of the patch is. Includes fixup from Alex for missing mxs-lradc-adc conversion. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210426174911.397061-2-jic23@kernel.org

iio: triggered-buffer: simplify devm_iio_triggered_buffer_setup_ext()

2021-05-17T12:49:07+00:00

Use devm_add_action_or_reset() instead of devres_alloc() and devres_add(), which works the same. This will simplify the code. There is no functional changes. Signed-off-by: Yicong Yang Reviewed-by: Lars-Peter Clausen Reviewed-by: Nuno Sa Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/1617881896-3164-5-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron

iio: hw_consumer: simplify devm_iio_hw_consumer_alloc()

2021-05-17T12:49:06+00:00

Use devm_add_action_or_reset() instead of devres_alloc() and devres_add(), which works the same. This will simplify the code. There is no functional changes. Signed-off-by: Yicong Yang Reviewed-by: Lars-Peter Clausen Reviewed-by: Nuno Sa Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/1617881896-3164-4-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: simplify __devm_iio_dmaengine_buffer_free()

2021-05-17T12:49:06+00:00

Use devm_add_action_or_reset() instead of devres_alloc() and devres_add(), which works the same. This will simplify the code. There is no functional changes. Signed-off-by: Yicong Yang Reviewed-by: Lars-Peter Clausen Reviewed-by: Nuno Sa Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/1617881896-3164-3-git-send-email-yangyicong@hisilicon.com Signed-off-by: Jonathan Cameron

iio: kfifo: add devm_iio_triggered_buffer_setup_ext variant

2021-03-25T19:13:52+00:00

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 Link: https://lore.kernel.org/r/20210311091042.22417-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron

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

2021-03-25T19:13:51+00:00

Should have been _kfifo_ and was _fifo_ Signed-off-by: Jonathan Cameron Acked-by: Alexandru Ardelean Reviewed-by: Lars-Peter Clausen Link: https://lore.kernel.org/r/20210314164655.408461-9-jic23@kernel.org

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

2021-03-25T19:13:49+00:00

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 Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210306162834.7339-1-ardeleanalex@gmail.com Signed-off-by: Jonathan Cameron