Re: [PATCH 2/2] Initial generic hypertransport interrupt support.

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Examples? details? patches?
> 
> Part of the problem with plain MSI is that you can't mask irqs at the
> source, in a generic way.

This is an interesting point, because this shows precisely the different
of approach between most HW PPC implementations vs what x86 does and
what the current code does...

Our MSIs are always routed as just additional sources to an existing IRQ
controller that will itself then handle things like masking, affinity,
etc...

Thus, we don't need nor want any kind of generic MSI code setting up an
irq_chip with enable/disable functions etc... Those should stay the ones
from the system's main PIC, maybe a different version of them, but
that's up to the system PIC to set that up.

That's one of the reason why I think we need to work the MSI arch side
API such that the MSI "controller" is the one to setup the irq_desc. The
"generic" mask/unmask/etc... using the MSI(X) config space can be
provided as optional helpers but it should be under arch, or more
specifically MSI controller control to pick up how to setup the irq_desc
and its associated irq_chip.

Another one is the fact that we have multiple different MSI mecanisms on
the same machines (like the Apple Quad G5 which have on one side an MSI
"register" that devices write to and that triggers sources on the MPIC,
and on the other side, HT interrupts which can be generated from MSIs by
the broadcom HT<->PCIe bridge). Thus that msi_ops stucture I've seen
around shall really be per PCI host bridge at the very least. One
propsal I have, but I didn't have time to actually implement it, was to
have the msi_ops pointer be a field in pci_bus that is inherited by
default. That is, the arch can call pci_set_msi_ops() on a given bus and
this will propagate to childs.

Anyway, as I said, I didn't have time to code that part. So it's mostly
food for thoughts.

Ben.