forked from luck/tmp_suning_uos_patched
f49196a5f5
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> |
||
|---|---|---|
| .. | ||
| qe_lib | ||
| cpm2_common.c | ||
| cpm2_pic.c | ||
| cpm2_pic.h | ||
| dart_iommu.c | ||
| dart.h | ||
| dcr.S | ||
| fsl_soc.c | ||
| fsl_soc.h | ||
| grackle.c | ||
| i8259.c | ||
| indirect_pci.c | ||
| ipic.c | ||
| ipic.h | ||
| Makefile | ||
| mmio_nvram.c | ||
| mpic.c | ||
| todc.c | ||
| tsi108_dev.c | ||
| tsi108_pci.c | ||