From f49196a5f53aa62a964b08ffa2c59699a0c8eb53 Mon Sep 17 00:00:00 2001 From: Scott Wood Date: Mon, 23 Oct 2006 11:35:22 -0500 Subject: [PATCH] [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 Signed-off-by: Paul Mackerras --- arch/powerpc/sysdev/ipic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c index bc4d4a7f9657..746f78c15375 100644 --- a/arch/powerpc/sysdev/ipic.c +++ b/arch/powerpc/sysdev/ipic.c @@ -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 -- 2.20.1