On 12/19/2011 10:29 AM, Lars-Peter Clausen wrote:
> We always hold the waitqueue lock when modifying the flags field. So it is safe
> to use the non-atomic bitops here instead of the atomic versions.
>
> The lock has to be held, because we need to clear the busy flag and flush the
> event fifo in one atomic operation when closing the event file descriptor.
Good spot. Glad to be rid of these. Thanks for doing this series, all
excellent tidying up and general reworking!
>
> Signed-off-by: Lars-Peter Clausen <lars@xxxxxxxxxx>
Acked-by: Jonathan Cameron <jic23@xxxxxxxxxx>
> ---
> drivers/staging/iio/industrialio-event.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/iio/industrialio-event.c b/drivers/staging/iio/industrialio-event.c
> index 58243d9..5e461e1 100644
> --- a/drivers/staging/iio/industrialio-event.c
> +++ b/drivers/staging/iio/industrialio-event.c
> @@ -124,7 +124,7 @@ static int iio_event_chrdev_release(struct inode *inode, struct file *filep)
> struct iio_event_interface *ev_int = filep->private_data;
>
> spin_lock(&ev_int->wait.lock);
> - clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> + __clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> /*
> * In order to maintain a clean state for reopening,
> * clear out any awaiting events. The mask will prevent
> @@ -153,7 +153,7 @@ int iio_event_getfd(struct iio_dev *indio_dev)
> return -ENODEV;
>
> spin_lock(&ev_int->wait.lock);
> - if (test_and_set_bit(IIO_BUSY_BIT_POS, &ev_int->flags)) {
> + if (__test_and_set_bit(IIO_BUSY_BIT_POS, &ev_int->flags)) {
> spin_unlock(&ev_int->wait.lock);
> return -EBUSY;
> }
> @@ -162,7 +162,7 @@ int iio_event_getfd(struct iio_dev *indio_dev)
> &iio_event_chrdev_fileops, ev_int, O_RDONLY);
> if (fd < 0) {
> spin_lock(&ev_int->wait.lock);
> - clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> + __clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> spin_unlock(&ev_int->wait.lock);
> }
> return fd;
--
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
