dect
/
linux-2.6
Archived
13
0
Fork 0
Code Releases Activity

[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>
This commit is contained in:
Scott Wood 2006-10-23 11:35:22 -05:00 committed by Paul Mackerras
parent f84c39da76
commit f49196a5f5
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
arch/powerpc/sysdev/ipic.c
View File

@ -473,9 +473,9 @@ static int ipic_set_irq_type(unsigned int virq, unsigned int flow_type)
desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
if (flow_type & IRQ_TYPE_LEVEL_LOW) {
desc->status |= IRQ_LEVEL;
set_irq_handler(virq, handle_level_irq);
desc->handle_irq = handle_level_irq;
} else {
set_irq_handler(virq, handle_edge_irq);
desc->handle_irq = handle_edge_irq;
}
/* only EXT IRQ senses are programmable on ipic