On Tue, Oct 26, 2021 at 10:25:04AM +0100, Mark Rutland wrote: > Now that entry code handles IRQ entry (including setting the IRQ regs) > before calling irqchip code, irqchip code can safely call > generic_handle_domain_irq(), and there's no functional reason for it to > call handle_domain_irq(). > > Let's cement this split of responsibility and remove handle_domain_irq() > entirely, updating irqchip drivers to call generic_handle_domain_irq(). > > For consistency, handle_domain_nmi() is similarly removed and replaced > with a generic_handle_domain_nmi() function which also does not perform > any entry logic. > > Previously handle_domain_{irq,nmi}() had a WARN_ON() which would fire > when they were called in an inappropriate context. So that we can > identify similar issues going forward, similar WARN_ON_ONCE() logic is > added to the generic_handle_*() functions, and comments are updated for > clarity and consistency. [...] > int generic_handle_domain_irq(struct irq_domain *domain, unsigned int hwirq) > { > + WARN_ON_ONCE(!in_irq()); > return handle_irq_desc(irq_resolve_mapping(domain, hwirq)); > } > EXPORT_SYMBOL_GPL(generic_handle_domain_irq); Why isn't the WARN_ON_ONCE() conditional on handle_enforce_irqctx()? (See handle_irq_desc() and c16816acd086.) I believe the above change causes a regression in drivers/gpio/gpio-dln2.c such that a gratuitous WARN splat is now emitted. Thanks, Lukas