Messages in this thread | | | Date | Tue, 01 Jun 2021 15:29:14 +0100 | From | Marc Zyngier <> | Subject | Re: [PATCH 00/39] irqdomain: Simplify interrupt handling |
| |
On Thu, 20 May 2021 17:37:12 +0100, Marc Zyngier <maz@kernel.org> wrote: > > Although most device drivers only deal with an interrupt number, the > core IRQ code is mostly concerned with the irq_desc structure that > describes the full interrupt context (hierarchy, handlers, state). > > However, the low-level interrupt handling code that relies on the > irqdomain abstraction has to perform an annoying dance to eventually > get the core code to invoke interrupt handlers: the irqdomain code > converts a low-level identifier to the unique Linux interrupt number, > and the core code resolves this into an irq_desc pointer. > > Each of these two lookups ends-up parsing a radix tree (although the > irqdomain code can use a linear mapping for the smallest domains), > which is obviously one too many. Wouldn't it be nice if the irqdomain > would cache the irq_desc instead of forcing the core code to look it > up on each and every interrupt? This is what this long series is all > about. > > There is roughly 3 parts here: > > - a substantial amount of massaging for some architectures (nios, mips > and powerpc) to disentangle weird include constructs (asm/irq.h > including linux/irqdomain.h is pretty bad...) and simplify bits of > the irqdomain code > > - some rework of the irqdomain code to allow the caching of a irq_data > pointer, unify the RCU behaviour and offer new APIs. > > - Perform a bulk of conversions that turn constructs similar to > generic_handle_irq(irq_find_mapping(domain, hwirq)) into a simpler > call to generic_handle_domain_irq(domain, hwirq). Yes, this is a > mouthful. > > I've kept most of the conversions per-subsystem/per-arch in order to > keep the number of patches low (though it is debatable whether I have > succeeded). > > This ends up with a negative diffstat, so it can't be completely bad! > Given the breadth of the changes, I do expect some breakage, although > I've extensively compile-tested it and the kbuild robot has been > invaluable in helping with the coverage.
Slight nudge in the direction of the cc'd arch maintainers. I'd like to take the core of this series into -next (in practice, patches #1 through to #27). Any comment on the early, arch-specific patches would be most welcome.
Thanks,
M.
-- Without deviation from the norm, progress is not possible.
| |