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

Merge branch 'togreg' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git

2026-09-07T13:29:07+00:00

# Conflicts: # drivers/iio/adc/ade9000.c

Merge branch 'fixes-togreg' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git

2026-09-07T11:56:06+00:00

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: drop dead max_size computation

2026-08-31T01:58:30+00:00

iio_dmaengine_buffer_submit_block() computes max_size unconditionally at the top of the function, but only the fileio branch consumes it - and that branch already computes it again right where it is used. Drop the unconditional copy. No functional change intended. Signed-off-by: Nuno Sá Signed-off-by: Jonathan Cameron

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

2026-08-30T23:52:42+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