On 10/04/13 12:07, Lars-Peter Clausen wrote:
> Since the kernel now disables all buffers when a device is unregistered it might
> happen that a in-kernel consumer tries to disable that buffer again. So ignore
> requests where the buffer already is in the desired state.
>
> Signed-off-by: Lars-Peter Clausen <lars@xxxxxxxxxx>
> ---
> No changes since v1
> ---
> drivers/iio/industrialio-buffer.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> index d6a5455..fd3f3af 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -681,9 +681,23 @@ int iio_update_buffers(struct iio_dev *indio_dev,
> {
> int ret;
>
> + if (insert_buffer == remove_buffer)
> + return 0;
> +
> mutex_lock(&indio_dev->info_exist_lock);
> mutex_lock(&indio_dev->mlock);
>
> + if (insert_buffer && iio_buffer_is_active(insert_buffer))
> + insert_buffer = NULL;
> +
> + if (remove_buffer && !iio_buffer_is_active(remove_buffer))
> + remove_buffer = NULL;
> +
So this condition will occur iff insert_buffer = 0 and remove buffer = 0?
If so, then insert_buffer == remove_buffer and you'll have already returned 0 above??
Entirely possible I'm needing more coffee this morning...
> + if (!insert_buffer && !remove_buffer) {
> + ret = 0;
> + goto out_unlock;
> + }
> +
> if (indio_dev->info == NULL) {
> ret = -ENODEV;
> goto out_unlock;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
