All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Walls <awalls@md.metrocast.net>
To: linux-media@vger.kernel.org
Subject: [PATCH 06/13] lirc_zilog: Don't acquire the rx->buf_lock in the poll() function
Date: Thu, 17 Feb 2011 20:16:52 -0500	[thread overview]
Message-ID: <1297991812.9399.22.camel@localhost> (raw)
In-Reply-To: <1297991502.9399.16.camel@localhost>


There is no need to take the rx->buf_lock in the the poll() function
as all the underling calls made on objects in the rx->buf lirc_buffer object
are protected by spinlocks.

Corrected a bad error return value in poll(): return POLLERR instead
of -ENODEV.

Added some comments to poll() for when, in the future, I forget what
poll() and poll_wait() are supposed to do.

Signed-off-by: Andy Walls <awalls@md.metrocast.net>
---
 drivers/staging/lirc/lirc_zilog.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/lirc/lirc_zilog.c b/drivers/staging/lirc/lirc_zilog.c
index 720ef67..dfa6a42 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -985,19 +985,26 @@ static unsigned int poll(struct file *filep, poll_table *wait)
 	unsigned int ret;
 
 	dprintk("poll called\n");
-	if (rx == NULL)
-		return -ENODEV;
 
-	mutex_lock(&rx->buf_lock);
+	if (rx == NULL) {
+		/*
+		 * Revisit this, if our poll function ever reports writeable
+		 * status for Tx
+		 */
+		dprintk("poll result = POLLERR\n");
+		return POLLERR;
+	}
 
+	/*
+	 * Add our lirc_buffer's wait_queue to the poll_table. A wake up on
+	 * that buffer's wait queue indicates we may have a new poll status.
+	 */
 	poll_wait(filep, &rx->buf.wait_poll, wait);
 
-	dprintk("poll result = %s\n",
-		lirc_buffer_empty(&rx->buf) ? "0" : "POLLIN|POLLRDNORM");
-
+	/* Indicate what ops could happen immediately without blocking */
 	ret = lirc_buffer_empty(&rx->buf) ? 0 : (POLLIN|POLLRDNORM);
 
-	mutex_unlock(&rx->buf_lock);
+	dprintk("poll result = %s\n", ret ? "POLLIN|POLLRDNORM" : 0);
 	return ret;
 }
 
-- 
1.7.2.1




  parent reply	other threads:[~2011-02-18  1:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18  1:11 [PATCH 0/13] lirc_zilog: Ref-counting and locking cleanup Andy Walls
2011-02-18  1:12 ` [PATCH 01/13] lirc_zilog: Restore checks for existence of the IR_tx object Andy Walls
2011-02-18  1:13 ` [PATCH 02/13] lirc_zilog: Remove broken, ineffective reference counting Andy Walls
2011-02-18  1:14 ` [PATCH 03/13] lirc_zilog: Convert ir_device instance array to a linked list Andy Walls
2011-02-18  1:15 ` [PATCH 04/13] lirc_zilog: Convert the instance open count to an atomic_t Andy Walls
2011-02-18  1:15 ` [PATCH 05/13] lirc_zilog: Use kernel standard methods for marking device non-seekable Andy Walls
2011-02-18  1:16 ` Andy Walls [this message]
2011-02-18  1:17 ` [PATCH 07/13] lirc_zilog: Remove unneeded rx->buf_lock Andy Walls
2011-02-18  1:18 ` [PATCH 08/13] lirc_zilog: Always allocate a Rx lirc_buffer object Andy Walls
2011-02-18  1:19 ` [PATCH 09/13] lirc_zilog: Move constants from ir_probe() into the lirc_driver template Andy Walls
2011-02-18  1:20 ` [PATCH 10/13] lirc_zilog: Add ref counting of struct IR, IR_tx, and IR_rx Andy Walls
2011-02-18  1:20 ` [PATCH 11/13] lirc_zilog: Add locking of the i2c_clients when in use Andy Walls
2011-02-18  1:21 ` [PATCH 12/13] lirc_zilog: Fix somewhat confusing information messages in ir_probe() Andy Walls
2011-02-18  1:22 ` [PATCH 13/13] lirc_zilog: Update TODO list based on work completed and revised plans Andy Walls
2011-03-06  4:00 ` [PATCH 0/13] lirc_zilog: Ref-counting and locking cleanup Jarod Wilson

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=1297991812.9399.22.camel@localhost \
    --to=awalls@md.metrocast.net \
    --cc=linux-media@vger.kernel.org \
    /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.