kernel/include/linux/iio/iio-opaque.h, branch linux-6.17.y

iio: core: fix doc reference to iio_push_to_buffers_with_ts_unaligned

2024-12-07T17:52:44Z

Use the right name of the function, which is defined in drivers/iio/industrialio-buffer.c Signed-off-by: Javier Carrasco Link: https://patch.msgid.link/20241125-iio_memset_scan_holes-v1-11-0cb6e98d895c@gmail.com Signed-off-by: Jonathan Cameron

iio: Convert unsigned to unsigned int

2024-10-12T11:41:24Z

Simple type conversion with no functional change implied. Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20241010181535.3083262-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron

iio: core: move 'mlock' to 'struct iio_dev_opaque'

2022-11-23T19:44:00Z

Now that there are no more users accessing 'mlock' directly, we can move it to the iio_dev private structure. Hence, it's now explicit that new driver's should not directly use this lock. Signed-off-by: Nuno Sá Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221012151620.1725215-5-nuno.sa@analog.com Signed-off-by: Jonathan Cameron

iio: Use per-device lockdep class for mlock

2022-09-05T17:08:42Z

If an IIO driver uses callbacks from another IIO driver and calls iio_channel_start_all_cb() from one of its buffer setup ops, then lockdep complains due to the lock nesting, as in the below example with lmp91000. Since the locks are being taken on different IIO devices, there is no actual deadlock. Fix the warning by telling lockdep to use a different class for each iio_device. ============================================ WARNING: possible recursive locking detected -------------------------------------------- python3/23 is trying to acquire lock: (&indio_dev->mlock){+.+.}-{3:3}, at: iio_update_buffers but task is already holding lock: (&indio_dev->mlock){+.+.}-{3:3}, at: enable_store other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&indio_dev->mlock); lock(&indio_dev->mlock); *** DEADLOCK *** May be due to missing lock nesting notation 5 locks held by python3/23: #0: (sb_writers#5){.+.+}-{0:0}, at: ksys_write #1: (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter #2: (kn->active#14){.+.+}-{0:0}, at: kernfs_fop_write_iter #3: (&indio_dev->mlock){+.+.}-{3:3}, at: enable_store #4: (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_update_buffers Call Trace: __mutex_lock iio_update_buffers iio_channel_start_all_cb lmp91000_buffer_postenable __iio_update_buffers enable_store Fixes: 67e17300dc1d76 ("iio: potentiostat: add LMP91000 support") Signed-off-by: Vincent Whitchurch Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220829091840.2791846-1-vincent.whitchurch@axis.com Signed-off-by: Jonathan Cameron

iio: core: Move the currentmode entry to the opaque structure

2022-04-10T15:23:01Z

This entry should, under no situation, be modified by device drivers. Now that we have limited its read access to device drivers really needing it and did so through a dedicated helper, we can easily move this variable to the opaque structure in order to prevent any further modification from non-authorized code (out of the core, basically). Signed-off-by: Miquel Raynal Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20220207143840.707510-12-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron

iio: core: Introduce iio_push_to_buffers_with_ts_unaligned()

2021-10-19T07:29:22Z

Whilst it is almost always possible to arrange for scan data to be read directly into a buffer that is suitable for passing to iio_push_to_buffers_with_timestamp(), there are a few places where leading data needs to be skipped over. For these cases introduce a function that will allocate an appropriate sized and aligned bounce buffer (if not already allocated) and copy the unaligned data into that before calling iio_push_to_buffers_with_timestamp() on the bounce buffer. We tie the lifespace of this buffer to that of the iio_dev.dev which should ensure no memory leaks occur. Signed-off-by: Jonathan Cameron Reviewed-by: Nuno Sá Link: https://lore.kernel.org/r/20210613151039.569883-2-jic23@kernel.org

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

2021-05-17T12:54:21Z

There is already an acessor function used to access it, making this move straight forward. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210426174911.397061-10-jic23@kernel.org

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

2021-05-17T12:54:21Z

No reason any driver should ever need access to this field, so hide it. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210426174911.397061-9-jic23@kernel.org

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

2021-05-17T12:54:17Z

No reason for this to be exposed to the drivers, so lets move it to the opaque structure. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210426174911.397061-8-jic23@kernel.org

iio: core: move @info_exist_lock to struct iio_dev_opaque

2021-05-17T12:49:13Z

This lock is only of interest to the IIO core, so make it only visible there. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210426174911.397061-7-jic23@kernel.org