[PATCHv7 07/13] irqdomain: add function to find a MSI irq_domain
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