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

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

iio: core: move @scan_index_timestamp to struct iio_dev_opaque

2021-05-17T12:49:13Z

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

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

2021-05-17T12:49:13Z

This is only set via the iio_trig_set_immutable() call and later used by the IIO core so there is no benefit in drivers being able to access it. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210426174911.397061-5-jic23@kernel.org

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

2021-05-17T12:49:13Z

Continuing move to hide internal elements from drivers, move this structure element over. It's only accessed from iio core files so this one was straight forward and no accessor functions are needed. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210426174911.397061-4-jic23@kernel.org