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:

quoted

Em 28-07-2010 12:14, Maxim Levitsky escreveu:

quoted

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.

-- 
Jarod Wilson
jarod@redhat.com