Messages in this thread | | | Date | Fri, 6 May 2022 22:32:42 +0200 | From | Lukas Wunner <> | Subject | Re: [PATCH v2 17/17] irq: remove handle_domain_{irq,nmi}() |
| |
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
| |