Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi

From: Marc Zyngier
Date: Wed Sep 02 2015 - 10:15:12 EST

On 02/09/15 14:25, Qais Yousef wrote:
> On 09/02/2015 12:53 PM, Marc Zyngier wrote:
>> On 02/09/15 11:48, Qais Yousef wrote:
>>> It's worth noting in the light of this that INT_SPEC should be optional
>>> since for hardware similar to mine there's not much to tell the
>>> controller if it's all dynamic except where we want the IPI to be routed
>>> to - the INT_SPEC is implicitly defined by the notion it's an IPI.
>> Well, I'd think that the INT_SPEC should say that it is an IPI, and I
>> don't believe we should omit it. On the ARM GIC side, our interrupts are
>> typed (type 0 is a normal wired interrupt, type 1 a per-cpu interrupt,
>> and we could allocate type 2 to identify an IPI).
> I didn't mean to omit it completely, but just being optional so it's
> specified if the intc needs this info only. I'm assuming that INT_SPEC
> is interrupt controller specific. If not, then ignore me :-)

It is, but I don't think it can really be made optional.

>> But we do need to identify it properly, as we should be able to cover
>> both IPIs and normal wired interrupts.
> I'm a bit confused here. What do you mean by normal wired interrupts? I
> thought this DT binding is only to describe IPIs that needs reserving
> and routing. What am I missing?

Look at my initial proposal, and the way I was describing a device
having an interrupt source, and two possible interrupt sinks, one being
a CPU and the other being another device.

I'm looking at solving that case as well, possibly with the same
infrastructure (the routing bit should be the same).


Jazz is not dead. It just smells funny...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at