kernel.git/drivers/iio/industrialio-buffer.c, branch linux-5.9.y

iio: buffer: fix attach/detach pollfunc order

2020-07-15T12:04:44Z

The original patch was error-ed by the submitter (me) and not by the author (Lars). After looking through the discussion logs (on email), it seems that this order was wrong for the start, even though the order implemented in the drivers was correct. Discussions: - first RFC: https://lore.kernel.org/linux-iio/20180622135322.3459-1-alexandru.ardelean@analog.com/ - 2nd patch: https://lore.kernel.org/linux-iio/20181219140912.22582-1-alexandru.ardelean@analog.com/ - final patch-sets: https://lore.kernel.org/linux-iio/20200522104632.517470-1-alexandru.ardelean@analog.com/ https://lore.kernel.org/linux-iio/20200525113855.178821-1-alexandru.ardelean@analog.com/ The last one was applied. The idea is that pollfunc should be attached before calling the 'indio_dev->setup_ops->postenable' hook and should be detached after calling the 'indio_dev->setup_ops->predisable' hook. While the drivers were updated to take this into account, the change to the IIO core was somehow omitted and was made wrong. This change fixes the order to the proper form. Fixes f11d59d87b862: ("iio: Move attach/detach of the poll func to the core") Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron

iio: core: move iio_dev's buffer_list to the private iio device object

2020-07-07T19:24:06Z

This change moves the 'buffer_list' away from the public IIO device object into the private part. Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron

iio: Move attach/detach of the poll func to the core

2020-06-20T16:34:44Z

All devices using a triggered buffer need to attach and detach the trigger to the device in order to properly work. Instead of doing this in each and every driver by hand move this into the core. At this point in time, all drivers should have been resolved to attach/detach the poll-function in the same order. This patch removes all explicit calls of iio_triggered_buffer_postenable() & iio_triggered_buffer_predisable() in all drivers, since the core handles now the pollfunc attach/detach. The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's not immediately obvious that removing the hooks doesn't break anything. Eugen was able to test on at91-sama5d2-adc driver, sama5d2-xplained board. All seems to be fine. Signed-off-by: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Tested-by: Eugen Hristev #for at91-sama5d2-adc Signed-off-by: Jonathan Cameron

iio: buffer: remove attrcount_orig var from sysfs creation

2020-05-16T16:57:15Z

The variable no longer does anything. It should have been removed with commit 2e036804d773e ("iio: buffer: remove 'scan_el_attrs' attribute group from buffer struct"). That was about the last time this was needed. Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron

iio: __iio_update_buffers: Update mode before preenable/after postdisable

2020-05-16T16:03:28Z

It is clear that we transition to INDIO_DIRECT_MODE when disabling the buffer(s) and it is also clear that we transition from INDIO_DIRECT_MODE when enabling the buffer(s). So leaving the currentmode field INDIO_DIRECT_MODE until after the preenable() callback and updating it to INDIO_DIRECT_MODE before the postdisable() callback doesn't add additional value. On the other hand some drivers will need to perform different actions depending on which mode the device is going to operate in/was operating in. Moving the update of currentmode before preenable() and after postdisable() enables us to have drivers which perform mode dependent actions in those callbacks. Note, was originally not intended as such, but fixes an issue introduced in the at91-sama5d2 adc driver. Signed-off-by: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Fixes: 065056cb0d0a ("iio: at91-sama5d2_adc: split at91_adc_current_chan_is_touch() helper") Tested-by: Eugen Hristev Signed-off-by: Jonathan Cameron

iio: buffer: extend short-hand use for 'indio_dev->buffer'

2020-05-03T08:47:21Z

This change is both cosmetic and a prequel to adding support for attaching multiple buffers per IIO device. The IIO buffer sysfs attrs are mostly designed to support only one attached buffer, and in order to support more, we need to centralize [in each attr function] the buffer which is being accessed. This also makes it a bit more uniform, as in some functions there is a short-hand 'buffer' variable and at the same time the 'indio_dev->buffer' is still access directly. Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron

iio: buffer: remove 'scan_el_attrs' attribute group from buffer struct

2020-04-19T15:56:34Z

This field doesn't seem used. It seems that only 'buffer->attrs' was ever used to extend sysfs attributes for an IIO buffer. Moving forward, it may not make sense to keep it. This patch removes the field and it's initialization code. Since we want to rework IIO buffer, to be able to add more buffers per IIO device, we will merge [somehow] the 'buffer' & 'scan_elements' groups, and we will continue to add the attributes to the 'buffer' group. Removing it here, will also make the rework here a bit smaller, since this code will not be present. Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron

iio: buffer: Don't allow buffers without any channels enabled to be activated

2020-04-19T15:56:14Z

Before activating a buffer make sure that at least one channel is enabled. Activating a buffer with 0 channels enabled doesn't make too much sense and disallowing this case makes sure that individual driver don't have to add special case code to handle it. Currently, without this patch enabling a buffer is possible and no error is produced. With this patch -EINVAL is returned. An example of execution with this patch and some instrumented print-code: root@analog:~# cd /sys/bus/iio/devices/iio\:device3/buffer root@analog:/sys/bus/iio/devices/iio:device3/buffer# echo 1 > enable 0: iio_verify_update 748 indio_dev->masklength 2 *insert_buffer->scan_mask 00000000 1: iio_verify_update 753 2:__iio_update_buffers 1115 ret -22 3: iio_buffer_store_enable 1241 ret -22 -bash: echo: write error: Invalid argument 1, 2 & 3 are exit-error paths. 0 the first print in iio_verify_update() rergardless of error path. Without this patch (and same instrumented print-code): root@analog:~# cd /sys/bus/iio/devices/iio\:device3/buffer root@analog:/sys/bus/iio/devices/iio:device3/buffer# echo 1 > enable 0: iio_verify_update 748 indio_dev->masklength 2 *insert_buffer->scan_mask 00000000 root@analog:/sys/bus/iio/devices/iio:device3/buffer# Buffer is enabled with no error. Note from Jonathan: Probably not suitable for automatic application to stable. This has been there from the very start. It tidies up an odd corner case but won't effect any 'real' users. Fixes: 84b36ce5f79c0 ("staging:iio: Add support for multiple buffers") Signed-off-by: Lars-Peter Clausen Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron

iio: buffer: re-introduce bitmap_zalloc() for trialmask

2020-04-19T15:56:13Z

Commit 3862828a903d3 ("iio: buffer: Switch to bitmap_zalloc()") introduced bitmap_alloc(), but commit 20ea39ef9f2f9 ("iio: Fix scan mask selection") reverted it. This change adds it back. The only difference is that it's adding bitmap_zalloc(). There might be some changes later that would require initializing it to zero. In any case, now it's already zero-ing the trialmask. Appears to have been the result of merge conflict resolution rather than an intentional revert. Reviewed-by: Andy Shevchenko Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron

Merge 5.5-rc7 into staging-next

2020-01-22T08:05:34Z

We want the staging fixes in here as well Signed-off-by: Greg Kroah-Hartman