On Mon, Feb 22, 2021 at 10:48:11AM +0000, Marc Zyngier wrote: > On 2021-02-22 09:59, Mark Rutland wrote: > > On Fri, Feb 19, 2021 at 11:39:01AM +0000, Mark Rutland wrote: > > > +void (*handle_arch_irq)(struct pt_regs *) __ro_after_init = > > > default_handle_irq; > > > > > > int __init set_handle_irq(void (*handle_irq)(struct pt_regs *)) > > > { > > > - if (handle_arch_irq) > > > + if (handle_arch_irq != default_handle_irq) > > > return -EBUSY; > > > > > > handle_arch_irq = handle_irq; > > > @@ -87,7 +92,7 @@ void __init init_IRQ(void) > > > init_irq_stacks(); > > > init_irq_scs(); > > > irqchip_init(); > > > - if (!handle_arch_irq) > > > + if (handle_arch_irq == default_handle_irq) > > > panic("No interrupt controller found."); > > It also seems odd to have both default_handle_irq() that panics, > and init_IRQ that panics as well. Not a big deal, but maybe > we should just drop this altogether and get the firework on the > first interrupt.
My gut feeling was that both were useful, and served slightly different cases: * The panic in default_handle_irq() helps if we unexpectedly unmask IRQ too early. This is mostly a nicety over the current behaviour of branching to NULL in this case. * The panic in init_IRQ() gives us a consistent point at which we can note the absence of a root IRQ controller even if all IRQs are quiescent. This is a bit nicer to debug than seeing a load of driver probes fail their request_irq() or whatever. ... so I'd err on the side of keeping both, but if you think otherwise I'm happy to change this. Thanks, Mark.