mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-12 05:48:40 +00:00
![]() 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> |
||
---|---|---|
.. | ||
alpha | ||
arm | ||
arm26 | ||
avr32 | ||
cris | ||
frv | ||
h8300 | ||
i386 | ||
ia64 | ||
m32r | ||
m68k | ||
m68knommu | ||
mips | ||
parisc | ||
powerpc | ||
ppc | ||
s390 | ||
sh | ||
sh64 | ||
sparc | ||
sparc64 | ||
um | ||
v850 | ||
x86_64 | ||
xtensa |