From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Jarod Wilson <jarod@redhat.com>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>,
lirc-list@lists.sourceforge.net,
Jarod Wilson <jarod@wilsonet.com>,
linux-input@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH 3/9] IR: replace spinlock with mutex.
Date: Wed, 28 Jul 2010 15:37:28 -0300 [thread overview]
Message-ID: <4C5078E8.5010409@redhat.com> (raw)
In-Reply-To: <20100728174338.GD26480@redhat.com>
Em 28-07-2010 14:43, Jarod Wilson escreveu:
> On Wed, Jul 28, 2010 at 07:32:58PM +0300, Maxim Levitsky wrote:
>> On Wed, 2010-07-28 at 13:03 -0300, Mauro Carvalho Chehab wrote:
>>> Em 28-07-2010 12:14, Maxim Levitsky escreveu:
>>>> Some handlers (lirc for example) allocates memory on initialization,
>>>> doing so in atomic context is cumbersome.
>>>> Fixes warning about sleeping function in atomic context.
>>>
>>> You should not replace it by a mutex, as the decoding code may happen during
>>> IRQ time on several drivers.
>> I though decoding code is run by a work queue?
>
> Yeah, it is. (INIT_WORK(&ir->raw->rx_work, ir_raw_event_work); in
> ir_raw_event_register).
>
>> I don't see any atomic codepath here...
>
> I think the ir_raw_event_store variants are the only things that are run
> from an interrupt context, and none of them touch ir_raw_handler_lock.
> That lock is advertised as being for the protection of ir_raw_handler_list
> and ir_raw_client_list, which are primarily manipulated by
> register/unregister functions, and we just lock them when doing actual IR
> decode work (via said work queue) so we don't feed raw IR somewhere that
> we shouldn't. I think Maxim is correct here, we should be okay with
> changing this to a mutex, unless I'm missing something else.
You're probably right. The previous code used to do this at IRQ time, but a latter
patch changed it to happen via a workqueue.
So, I'm OK with this patch.
Cheers,
Mauro.
next prev parent reply other threads:[~2010-07-28 18:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 15:14 [PATCH 0/9 v1] IR: few fixes, additions and ENE driver Maxim Levitsky
2010-07-28 15:14 ` [PATCH 1/9] IR: Kconfig fixes Maxim Levitsky
2010-07-28 17:36 ` Randy Dunlap
2010-07-28 20:31 ` Maxim Levitsky
2010-07-28 15:14 ` [PATCH 2/9] IR: minor fixes: Maxim Levitsky
2010-07-28 16:01 ` Mauro Carvalho Chehab
2010-07-28 16:38 ` Maxim Levitsky
2010-07-28 17:59 ` Mauro Carvalho Chehab
2010-07-28 17:23 ` Jarod Wilson
2010-07-28 15:14 ` [PATCH 3/9] IR: replace spinlock with mutex Maxim Levitsky
2010-07-28 16:03 ` Mauro Carvalho Chehab
2010-07-28 16:32 ` Maxim Levitsky
2010-07-28 17:43 ` Jarod Wilson
2010-07-28 18:37 ` Mauro Carvalho Chehab [this message]
2010-07-28 15:14 ` [PATCH 4/9] IR: add helper functions for ir input devices that send ir timing data in small chunks, and alternation between pulses and spaces isn't guaranteed Maxim Levitsky
2010-07-28 16:09 ` Mauro Carvalho Chehab
2010-07-28 16:29 ` Maxim Levitsky
2010-07-28 17:46 ` Jarod Wilson
2010-07-28 20:57 ` Jarod Wilson
2010-07-28 21:16 ` Maxim Levitsky
2010-07-28 15:14 ` [PATCH 5/9] IR: extend interfaces to support more device settings Maxim Levitsky
2010-07-28 17:00 ` Mauro Carvalho Chehab
2010-07-28 20:47 ` Jarod Wilson
2010-07-28 15:14 ` [PATCH 6/9] IR: actually allow not to compile keymaps in Maxim Levitsky
2010-07-28 17:58 ` Jarod Wilson
2010-07-28 15:14 ` [PATCH 7/9] IR: actualy report unknown scancodes the in-kernel decoders found Maxim Levitsky
2010-07-28 15:14 ` [PATCH 8/9] IR: Add ENE input driver Maxim Levitsky
2010-07-28 17:10 ` Mauro Carvalho Chehab
2010-07-28 17:13 ` Maxim Levitsky
2010-07-28 17:17 ` Jarod Wilson
2010-07-28 18:13 ` Mauro Carvalho Chehab
2010-07-28 15:14 ` [PATCH 9/9] STAGING: remove ENE driver Maxim Levitsky
-- strict thread matches above, loose matches on Subject: below --
2010-07-28 23:40 (unknown), Maxim Levitsky
2010-07-28 23:40 ` [PATCH 3/9] IR: replace spinlock with mutex Maxim Levitsky
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=4C5078E8.5010409@redhat.com \
--to=mchehab@redhat.com \
--cc=jarod@redhat.com \
--cc=jarod@wilsonet.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lirc-list@lists.sourceforge.net \
--cc=maximlevitsky@gmail.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.