[POWERPC] IPIC: Fix spinlock recursion in set_irq_handler
authorScott Wood <scottwood@freescale.com>
Mon, 23 Oct 2006 16:35:22 +0000 (11:35 -0500)
committerPaul Mackerras <paulus@samba.org>
Wed, 25 Oct 2006 03:49:22 +0000 (13:49 +1000)
commitf49196a5f53aa62a964b08ffa2c59699a0c8eb53
tree3400c448ec36f07681d6ab9541e175e2818c772c
parentf84c39da766b4c8f13872282f58286a57ad05b3e
[POWERPC] IPIC: Fix spinlock recursion in set_irq_handler

This causes ipic_set_irq_type to set the handler directly rather
than call set_irq_handler, which causes spinlock recursion because
the lock is already held when ipic_set_irq_type is called.

I'm also not convinced that ipic_set_irq_type should be changing the
handler at all.  There seem to be several controllers that don't and
several that do.  Those that do would break what appears to be a common
usage of calling set_irq_chip_and_handler followed by set_irq_type, if a
non-standard handler were to be used.  OTOH, irq_create_of_mapping()
doesn't set the handler, but only calls set_irq_type().

This patch gets things working in the spinlock-debugging-enabled case,
but I'm curious as to where the handler setting is ideally supposed to be
done.  I don't see any documentation on set_irq_type() that clarifies
what the semantics are supposed to be.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
arch/powerpc/sysdev/ipic.c