kernel/git/next/linux-next.git/drivers/iio/buffer, branch master

iio: buffer-dmaengine: fix sg entry iteration when building dma_vecs

2026-08-30T00:19:07+00:00

iio_dmaengine_buffer_submit_block() counts scatterlist entries with sg_nents_for_len(), which walks the CPU-side lengths (sg->length), but then consumes the DMA-side fields (sg_dma_address()/sg_dma_len()). After dma_map_sgtable() the two views may differ: an IOMMU can coalesce the mapping so that only the first sgt->nents entries carry valid DMA addresses, with nents < orig_nents. On x86 with an IOMMU enabled, a DMABUF block backed by two 1 MiB system-heap chunks maps to a single 2 MiB IOVA range. The CPU-side count is 2, so the loop reads one entry past the mapped set and emits a garbage vec ({addr = ~0, len = 0}). The DMA engine driver rejects the vec array (prep returns NULL), the fence is signalled with -ENOMEM, which a userspace poller cannot observe, and the block is left in ACTIVE state so every further enqueue of it fails with -EBUSY. The visible symptom is a stream of zero-filled blocks followed by a wedged buffer. Platforms without an IOMMU never hit this because nents == orig_nents. Size the vec array with sgt->nents, i.e. the DMA-mapped view, and stop the fill loop once bytes_used is covered - which is allowed to be smaller than the block size - passing the number of vecs actually filled to dmaengine_prep_peripheral_dma_vec(). One vec per mapped entry is enough since coalescing can only ever reduce the number of entries. A single mapped entry longer than the device's maximum segment size would need more than one, but the DMA API already assumes no single segment exceeds it [1], and splitting a vec down to the hardware descriptor size is the DMA engine driver's job - which both current .device_prep_peripheral_dma_vec() implementations do. [1]: commit ab2cbeb0ed30 ("iommu/dma: Handle SG length overflow better") Assisted-by: Claude:claude-fable-5 Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API") Signed-off-by: Michael Hennerich Signed-off-by: Nuno Sá Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron

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

iio: inkern: Use namespaced exports

2026-07-05T00:37:19+00:00

Use namespaced exports for IIO consumer API functions. This will make it easier to manage the IIO export surface. Consumer drivers will only be provided access to a specific set of functions, thereby restricting usage of internal IIO functions by other parts of the kernel. This change cannot be split into several parts without breaking bisectability, thus all of the affected drivers are modified at once. Acked-by: Sebastian Reichel # for power-supply Acked-by: Guenter Roeck Reviewed-by: Andy Shevchenko Signed-off-by: Romain Gantois Acked-by: Dmitry Torokhov Acked-by: Vinod Koul Signed-off-by: Jonathan Cameron

iio: buffer: hw-consumer: free scan_mask on buffer release

2026-05-26T18:22:56+00:00

The scan_mask lifetime changed in commit 9a2e1233d38c ("iio: buffer: hw-consumer: remove redundant scan_mask flexible array"). Before that change, the scan mask storage was embedded in struct hw_consumer_buffer, so iio_hw_buf_release() could free the whole allocation with a single kfree(hw_buf). That commit moved the scan mask to a separate bitmap_zalloc() allocation stored in buffer.scan_mask, but left iio_hw_buf_release() unchanged. Free the scan mask in iio_hw_buf_release() before freeing the buffer wrapper. Fixes: 9a2e1233d38c ("iio: buffer: hw-consumer: remove redundant scan_mask flexible array") Signed-off-by: Felix Gu Reviewed-by: Nuno Sá Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron

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

2026-05-15T11:05:34+00:00

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

iio: buffer: hw-consumer: remove redundant scan_mask flexible array

2026-03-14T12:10:21+00:00

The scan_mask flexible array member in hw_consumer_buffer duplicates the scan_mask pointer already present in struct iio_buffer. Remove it and allocate the bitmap directly with bitmap_zalloc(), assigning it to buf->buffer.scan_mask. This simplifies the code and there's no need for the flex array allocation. Signed-off-by: Nuno Sá Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron

iio: core: Simplify IIO core managed APIs

2026-02-23T21:00:47+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. While at it, inline devm_iio_kfifo_allocate() into its only user. Reviewed-by: Nuno Sá Signed-off-by: Andy Shevchenko Signed-off-by: Jonathan Cameron

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

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

This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds

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