We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b0464b68d429bc8a3fe6595d19c39dfc4d95, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...
CC: Andy Walls <awalls@xxxxxxxxxxxxxxxx>
CC: stable@xxxxxxxxxx
Signed-off-by: Jarod Wilson <jarod@xxxxxxxxxx>
---
drivers/staging/lirc/lirc_zilog.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c b/drivers/staging/lirc/lirc_zilog.c
index dd6a57c..4e051f6 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -475,14 +475,14 @@ static int lirc_thread(void *arg)
dprintk("poll thread started\n");
while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
+
/* if device not opened, we can sleep half a second */
if (atomic_read(&ir->open_count) == 0) {
schedule_timeout(HZ/2);
continue;
}
- set_current_state(TASK_INTERRUPTIBLE);
-
/*
* This is ~113*2 + 24 + jitter (2*repeat gap + code length).
* We use this interval as the chip resets every time you poll
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
