From: Jonathan Cameron <jic23@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@cam.ac.uk>,
Michael Hennerich <michael.hennerich@analog.com>,
linux-iio@vger.kernel.org,
device-drivers-devel@blackfin.uclinux.org, drivers@analog.com
Subject: Re: [PATCH v2 4/6] staging:iio:events: Use waitqueue lock to protect event queue
Date: Sun, 29 Jan 2012 18:18:37 +0000 [thread overview]
Message-ID: <4F258D7D.9090000@kernel.org> (raw)
In-Reply-To: <1324290580-17511-4-git-send-email-lars@metafoo.de>
On 12/19/2011 10:29 AM, Lars-Peter Clausen wrote:
> Use the waitqueue lock to protect the event queue instead of a custom mutex.
> This has the advantage that we can call the waitqueue operations with the lock
> held, which simplifies the code flow a bit.
>
> Acked-by: Jonathan Cameron <jic23@kernel.org>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Hmm.. I really should have noticed this before.. If this hasn't gone to
Greg already, can you also clear out the documentation for
event_list_lock within struct iio_event_interface. Cleaner to do it
here than in a follow up patch.
diff --git a/drivers/staging/iio/industrialio-event.c
b/drivers/staging/iio/industrialio-event.c
index 5e461e1..0703d6d 100644
--- a/drivers/staging/iio/industrialio-event.c
+++ b/drivers/staging/iio/industrialio-event.c
@@ -28,7 +28,6 @@
/**
* struct iio_event_interface - chrdev interface for an event line
* @wait: wait queue to allow blocking reads of events
- * @event_list_lock: mutex to protect the list of detected events
* @det_events: list of detected events
* @dev_attr_list: list of event interface sysfs attribute
* @flags: file operations related flags including busy flag.
> ---
> drivers/staging/iio/industrialio-event.c | 45 ++++++++++++-----------------
> 1 files changed, 19 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/staging/iio/industrialio-event.c b/drivers/staging/iio/industrialio-event.c
> index d63aa0b..b5f7a2c 100644
> --- a/drivers/staging/iio/industrialio-event.c
> +++ b/drivers/staging/iio/industrialio-event.c
> @@ -34,8 +34,7 @@
> * @group: event interface sysfs attribute group
> */
> struct iio_event_interface {
> - wait_queue_head_t wait;
> - struct mutex event_list_lock;
> + wait_queue_head_t wait;
> DECLARE_KFIFO(det_events, struct iio_event_data, 16);
>
> struct list_head dev_attr_list;
> @@ -50,19 +49,17 @@ int iio_push_event(struct iio_dev *indio_dev, u64 ev_code, s64 timestamp)
> int copied;
>
> /* Does anyone care? */
> - mutex_lock(&ev_int->event_list_lock);
> + spin_lock(&ev_int->wait.lock);
> if (test_bit(IIO_BUSY_BIT_POS, &ev_int->flags)) {
>
> ev.id = ev_code;
> ev.timestamp = timestamp;
>
> copied = kfifo_put(&ev_int->det_events, &ev);
> -
> - mutex_unlock(&ev_int->event_list_lock);
> if (copied != 0)
> - wake_up_interruptible(&ev_int->wait);
> - } else
> - mutex_unlock(&ev_int->event_list_lock);
> + wake_up_locked(&ev_int->wait);
> + }
> + spin_unlock(&ev_int->wait.lock);
>
> return 0;
> }
> @@ -80,28 +77,25 @@ static ssize_t iio_event_chrdev_read(struct file *filep,
> if (count < sizeof(struct iio_event_data))
> return -EINVAL;
>
> - mutex_lock(&ev_int->event_list_lock);
> + spin_lock(&ev_int->wait.lock);
> if (kfifo_is_empty(&ev_int->det_events)) {
> if (filep->f_flags & O_NONBLOCK) {
> ret = -EAGAIN;
> - goto error_mutex_unlock;
> + goto error_unlock;
> }
> - mutex_unlock(&ev_int->event_list_lock);
> /* Blocking on device; waiting for something to be there */
> - ret = wait_event_interruptible(ev_int->wait,
> + ret = wait_event_interruptible_locked(ev_int->wait,
> !kfifo_is_empty(&ev_int->det_events));
> if (ret)
> - goto error_ret;
> + goto error_unlock;
> /* Single access device so no one else can get the data */
> - mutex_lock(&ev_int->event_list_lock);
> }
>
> - mutex_unlock(&ev_int->event_list_lock);
> ret = kfifo_to_user(&ev_int->det_events, buf, count, &copied);
>
> -error_mutex_unlock:
> - mutex_unlock(&ev_int->event_list_lock);
> -error_ret:
> +error_unlock:
> + spin_unlock(&ev_int->wait.lock);
> +
> return ret ? ret : copied;
> }
>
> @@ -109,7 +103,7 @@ static int iio_event_chrdev_release(struct inode *inode, struct file *filep)
> {
> struct iio_event_interface *ev_int = filep->private_data;
>
> - mutex_lock(&ev_int->event_list_lock);
> + spin_lock(&ev_int->wait.lock);
> clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> /*
> * In order to maintain a clean state for reopening,
> @@ -117,7 +111,7 @@ static int iio_event_chrdev_release(struct inode *inode, struct file *filep)
> * any new __iio_push_event calls running.
> */
> kfifo_reset_out(&ev_int->det_events);
> - mutex_unlock(&ev_int->event_list_lock);
> + spin_unlock(&ev_int->wait.lock);
>
> return 0;
> }
> @@ -137,18 +131,18 @@ int iio_event_getfd(struct iio_dev *indio_dev)
> if (ev_int == NULL)
> return -ENODEV;
>
> - mutex_lock(&ev_int->event_list_lock);
> + spin_lock(&ev_int->wait.lock);
> if (test_and_set_bit(IIO_BUSY_BIT_POS, &ev_int->flags)) {
> - mutex_unlock(&ev_int->event_list_lock);
> + spin_unlock(&ev_int->wait.lock);
> return -EBUSY;
> }
> - mutex_unlock(&ev_int->event_list_lock);
> + spin_unlock(&ev_int->wait.lock);
> fd = anon_inode_getfd("iio:event",
> &iio_event_chrdev_fileops, ev_int, O_RDONLY);
> if (fd < 0) {
> - mutex_lock(&ev_int->event_list_lock);
> + spin_lock(&ev_int->wait.lock);
> clear_bit(IIO_BUSY_BIT_POS, &ev_int->flags);
> - mutex_unlock(&ev_int->event_list_lock);
> + spin_unlock(&ev_int->wait.lock);
> }
> return fd;
> }
> @@ -357,7 +351,6 @@ static bool iio_check_for_dynamic_events(struct iio_dev *indio_dev)
>
> static void iio_setup_ev_int(struct iio_event_interface *ev_int)
> {
> - mutex_init(&ev_int->event_list_lock);
> INIT_KFIFO(ev_int->det_events);
> init_waitqueue_head(&ev_int->wait);
> }
next prev parent reply other threads:[~2012-01-29 18:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-19 10:29 [PATCH v2 1/6] staging:iio: Update iio_event_interface documentation Lars-Peter Clausen
2011-12-19 10:29 ` [PATCH v2 6/6] staging:iio:events: Use non-atmoic bitops Lars-Peter Clausen
2011-12-19 20:59 ` Jonathan Cameron
2012-01-29 10:49 ` Jonathan Cameron
2011-12-19 20:55 ` [PATCH v2 1/6] staging:iio: Update iio_event_interface documentation Jonathan Cameron
2011-12-19 21:28 ` Lars-Peter Clausen
[not found] ` <1324290580-17511-2-git-send-email-lars@metafoo.de>
2011-12-19 20:56 ` [PATCH v2 2/6] staging:iio: Factor out event handling into its own file Jonathan Cameron
[not found] ` <1324290580-17511-3-git-send-email-lars@metafoo.de>
2011-12-19 20:56 ` [PATCH v2 3/6] staging:iio:events: Use kfifo for event queue Jonathan Cameron
[not found] ` <1324290580-17511-4-git-send-email-lars@metafoo.de>
2011-12-19 20:57 ` [PATCH v2 4/6] staging:iio:events: Use waitqueue lock to protect " Jonathan Cameron
2011-12-19 21:28 ` Lars-Peter Clausen
2012-01-29 18:18 ` Jonathan Cameron [this message]
2012-01-31 17:26 ` Lars-Peter Clausen
2012-01-31 20:58 ` Jonathan Cameron
-- strict thread matches above, loose matches on Subject: below --
2012-02-01 18:45 [PATCH v2 0/6] staging:iio: Event handling updates Lars-Peter Clausen
2012-02-01 18:45 ` [PATCH v2 4/6] staging:iio:events: Use waitqueue lock to protect event queue Lars-Peter Clausen
2012-02-01 21:17 [PATCH v2 0/6] staging:iio: Event handling updates Lars-Peter Clausen
2012-02-01 21:17 ` [PATCH v2 4/6] staging:iio:events: Use waitqueue lock to protect event queue Lars-Peter Clausen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F258D7D.9090000@kernel.org \
--to=jic23@kernel.org \
--cc=device-drivers-devel@blackfin.uclinux.org \
--cc=drivers@analog.com \
--cc=jic23@cam.ac.uk \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=michael.hennerich@analog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.