kernel/git/stable/linux.git/drivers/iio/buffer/industrialio-buffer-dmaengine.c, branch master

treewide: refresh kmalloc_obj() conversions

2026-09-05T04:37:00+00:00

This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook

iio: buffer-dmaengine: Add support for cyclic DMA transfers

2026-07-19T22:16:22+00:00

Allow buffer blocks flagged as cyclic to be submitted as repeating DMA transfers. For cyclic blocks, use DMA_PREP_REPEAT so the engine keeps replaying the descriptor. This is useful for output buffers where the same data should be driven continuously without userspace having to requeue it. Examples include continuous RF transmit paths replaying a calibration, test or beacon pattern. Skip installing the completion callback for cyclic blocks. Since the transfer is continuously replayed, the callback would fire on every period, throwing off the block refcount. Because nothing prevents a new cyclic transfer from replacing an already active cyclic one, always set DMA_PREP_LOAD_EOT so the engine correctly terminates the active transfer before loading the new descriptor. Limit the DMA buffer queue to one cyclic DMABUF at a time. There is currently no known use case for queueing multiple cyclic blocks, and cyclic blocks stay referenced until the buffer is disabled. Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

iio: buffer-dmaengine: Fix coding style complains

2025-12-21T12:01:55+00:00

Just making sure checkpatch is happy. No functional change intended. Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: Use the cleanup.h API

2025-12-21T12:01:00+00:00

Make use of the cleanup.h API for locks in order to simplify some code paths. Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: enable .get_dma_dev()

2025-10-13T07:38:08+00:00

Wire up the .get_dma_dev() callback to use the DMA buffer infrastructure's implementation. This ensures that DMABUF operations use the correct DMA device for mapping, which is essential for proper operation on systems where memory is mapped above the 32-bit range. Without this callback, the core would fall back to using the IIO device's parent, which may not have the appropriate DMA mask configuration for high memory access. Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API") Reviewed-by: David Lechner Signed-off-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: add devm_iio_dmaengine_buffer_setup_with_handle()

2025-02-10T18:47:49+00:00

Add a new devm_iio_dmaengine_buffer_setup_with_handle() function to handle cases where the DMA channel is managed by the caller rather than being requested and released by the iio_dmaengine module. Reviewed-by: Nuno Sa Signed-off-by: David Lechner Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-9-e48a489be48c@baylibre.com Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: split requesting DMA channel from allocating buffer

2025-02-10T18:47:29+00:00

Refactor the IIO dmaengine buffer code to split requesting the DMA channel from allocating the buffer. We want to be able to add a new function where the IIO device driver manages the DMA channel, so these two actions need to be separate. To do this, calling dma_request_chan() is moved from iio_dmaengine_buffer_alloc() to iio_dmaengine_buffer_setup_ext(). A new __iio_dmaengine_buffer_setup_ext() helper function is added to simplify error unwinding and will also be used by a new function in a later patch. iio_dmaengine_buffer_free() now only frees the buffer and does not release the DMA channel. A new iio_dmaengine_buffer_teardown() function is added to unwind everything done in iio_dmaengine_buffer_setup_ext(). This keeps things more symmetrical with obvious pairs alloc/free and setup/teardown. Calling dma_get_slave_caps() in iio_dmaengine_buffer_alloc() is moved so that we can avoid any gotos for error unwinding. Reviewed-by: Nuno Sa Signed-off-by: David Lechner Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-8-e48a489be48c@baylibre.com Signed-off-by: Jonathan Cameron

iio: buffer-dmaengine: document iio_dmaengine_buffer_setup_ext

2024-12-07T17:47:58+00:00

The iio_dmaengine_buffer_setup_ext() function is public and should be documented. Also, while touching this, fix the description of @dev in related functions. @dev does not strictly have to be the parent of the IIO device. It is only passed to dma_request_chan() so strictly speaking, it can be any device that is a valid DMA channel consumer. Signed-off-by: David Lechner Link: https://patch.msgid.link/20241115-dlech-mainline-spi-engine-offload-2-v5-9-bea815bd5ea5@baylibre.com Signed-off-by: Jonathan Cameron