[PATCHv7 07/13] irqdomain: add function to find a MSI irq_domain

Benjamin Herrenschmidt benh at kernel.crashing.org
Wed Aug 7 18:31:05 EDT 2013

On Thu, 2013-08-08 at 00:04 +0200, Thomas Petazzoni wrote:
> Again, this has been discussed at lengths in the previous iterations,
> for which I already gave you all the links, as you requested in a
> private e-mail. It'd be great if this discussion was read seriously,
> because I really have the feeling we are restarting from zero on this
> whole MSI thing...

Well, two things here:

 - You don't need my ack since I am not the maintainer of the irqdomain
code anymore, Grant is :-)

 - I still don't like it. I find that it's looking more and more like
over engineering. I don't like having any kind of infrastructure
relationship between MSI stuff and irqdomain, ie, a PCI/PCIe specific
construct and a generic interrupt remapper.

Trying to use irqdomain for HW number allocation seems to be pushing it
where it wasn't designed to go. Are those interrupts really different
domains ? Do they have separate number spaces, separate DT encodings and
overall characteristics ?

What's wrong with the bitmap allocator in the PIC driver ? It's simple,
and does the job just fine. If anything, take it from powerpc and sparc
and move it to generic. It's already a "generic" (ie shared)
infrastructure in powerpc.

Let's ask somebody of well known taste ... Thomas ! :-) (Yes, you tglx,
I know you are lurking ...). What do you reckon ?

That series makes me feel nervous, it feels like a hack. I really don't
like creating that relationship between msi_chip and irqdomain. In fact,
I think it makes it harder to understand what's happening in the code
and following things.

It's a LOT clearer to me to have an irq domain for the PIC and an
explicit bitmap allocation for MSIs, I see where things come from, I can
follow the code path etc... much more easily.

I suspect we have a case of over-abstracting happening here. This is a
dangerous illness and can be contagious :-)


More information about the linux-arm-kernel mailing list