Re: [PATCH v2] iio: buffer: Don't allow buffers without any channels enabled to be activated

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/26/20 8:42 AM, Ardelean, Alexandru wrote:
On Wed, 2020-03-25 at 17:57 +0200, Andy Shevchenko wrote:
[External]

On Wed, Mar 25, 2020 at 12:02 PM Alexandru Ardelean
<alexandru.ardelean@xxxxxxxxxx> wrote:
From: Lars-Peter Clausen <lars@xxxxxxxxxx>

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.

Signed-off-by: Lars-Peter Clausen <lars@xxxxxxxxxx>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@xxxxxxxxxx>
---

Changelog v1 -> v2:
* moved check in iio_verify_update()
* added dev_dbg() message; should help some folks understand the message
* documented steps to reproduce
* added Fixes tag; hopefully the tag is the good one; if needed, it can be
   dropped; this has been around for ~8 years; no idea if it's worth
   backporting
Where?
stable/fixes/lts-kernels
don't have a really good clue about where these things need backporting;
What Andy means is that there is no Fixes tag :)



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux