aboutsummaryrefslogtreecommitdiff
path: root/arch/m68k/mvme147
diff options
context:
space:
mode:
authorScott Wood <scottwood@freescale.com>2006-10-23 11:35:22 -0500
committerPaul Mackerras <paulus@samba.org>2006-10-25 13:49:22 +1000
commitf49196a5f53aa62a964b08ffa2c59699a0c8eb53 (patch)
tree3400c448ec36f07681d6ab9541e175e2818c772c /arch/m68k/mvme147
parentf84c39da766b4c8f13872282f58286a57ad05b3e (diff)
[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>
Diffstat (limited to 'arch/m68k/mvme147')
0 files changed, 0 insertions, 0 deletions