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á <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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á <nuno.sa@analog.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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 <torvalds@linux-foundation.org>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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 <kees@kernel.org>
Make use of the cleanup.h API for locks in order to simplify some code
paths.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
iio_dma_buffer_init() always return 0. Therefore there's no point in
returning int.
While at it, fix a mismatch between the function declaration and definition
regarding the struct device (dma_dev != dev).
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Make use of the cleanup.h API for locks and memory allocation in order
to simplify some code paths.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Don't use mutex_is_locked() + WARN_ON() for checking if a specif lock is
taken. Instead use the existing annotations which means
lockdep_assert_held().
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Pull char/misc/IIO driver updates from Greg KH:
"Here is the big set of char/misc/iio driver updates for 6.19-rc1. Lots
of stuff in here including:
- lots of IIO driver updates, cleanups, and additions
- large interconnect driver changes as they get converted over to a
dynamic system of ids
- coresight driver updates
- mwave driver updates
- binder driver updates and changes
- comedi driver fixes now that the fuzzers are being set loose on
them
- nvmem driver updates
- new uio driver addition
- lots of other small char/misc driver updates, full details in the
shortlog
All of these have been in linux-next for a while now"
* tag 'char-misc-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (304 commits)
char: applicom: fix NULL pointer dereference in ac_ioctl
hangcheck-timer: fix coding style spacing
hangcheck-timer: Replace %Ld with %lld
hangcheck-timer: replace printk(KERN_CRIT) with pr_crit
uio: Add SVA support for PCI devices via uio_pci_generic_sva.c
dt-bindings: slimbus: fix warning from example
intel_th: Fix error handling in intel_th_output_open
misc: rp1: Fix an error handling path in rp1_probe()
char: xillybus: add WQ_UNBOUND to alloc_workqueue users
misc: bh1770glc: use pm_runtime_resume_and_get() in power_state_store
misc: cb710: Fix a NULL vs IS_ERR() check in probe()
mux: mmio: Add suspend and resume support
virt: acrn: split acrn_mmio_dev_res out of acrn_mmiodev
greybus: gb-beagleplay: Fix timeout handling in bootloader functions
greybus: add WQ_PERCPU to alloc_workqueue users
char/mwave: drop typedefs
char/mwave: drop printk wrapper
char/mwave: remove printk tracing
char/mwave: remove unneeded fops
char/mwave: remove MWAVE_FUTZ_WITH_OTHER_DEVICES ifdeffery
...
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: 7a86d46998 ("iio: buffer-dmaengine: Support new DMABUF based userspace API")
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Implement the .get_dma_dev() callback for DMA buffers by returning the
device that owns the DMA channel. This allows the core DMABUF
infrastructure to properly map DMA buffers using the correct device,
avoiding the need for bounce buffers on systems where memory is mapped
above the 32-bit range.
The function returns the DMA queue's device, which is the actual device
responsible for DMA operations in buffer-dma implementations.
Cc: stable@vger.kernel.org
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Document that the callback registered with iio_channel_get_all_cb()
must be safe to call from any context since it is called from by
iio_push_to_buffer() which can be called in any context.
Signed-off-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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 <nuno.sa@analog.com>
Signed-off-by: David Lechner <dlechner@baylibre.com>
Link: https://patch.msgid.link/20250207-dlech-mainline-spi-engine-offload-2-v8-8-e48a489be48c@baylibre.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
