linux-kernel - Re: [PATCH 03/12] of: Add binding document for MIPS GIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <540665BA.3080702@gmail.com>
Date:	Tue, 02 Sep 2014 17:50:02 -0700
From:	David Daney <ddaney.cavm@...il.com>
To:	Andrew Bresticker <abrestic@...omium.org>
CC:	Ralf Baechle <ralf@...ux-mips.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Jeffrey Deans <jeffrey.deans@...tec.com>,
	Markos Chandras <markos.chandras@...tec.com>,
	Paul Burton <paul.burton@...tec.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jason Cooper <jason@...edaemon.net>,
	Linux-MIPS <linux-mips@...ux-mips.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/12] of: Add binding document for MIPS GIC

On 09/02/2014 12:36 PM, Andrew Bresticker wrote:
> On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm@...il.com> wrote:
>> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
>>>
>>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>>> can be used to route external interrupts to individual VPEs and CPU
>>> interrupt vectors.  It also supports a timer and software-generated
>>> interrupts.
>>>
>>> Signed-off-by: Andrew Bresticker <abrestic@...omium.org>
>>> ---
>>>    Documentation/devicetree/bindings/mips/gic.txt | 50
>>> ++++++++++++++++++++++++++
>>>    1 file changed, 50 insertions(+)
>>>    create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>>> b/Documentation/devicetree/bindings/mips/gic.txt
>>> new file mode 100644
>>> index 0000000..725f1ef
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>>> @@ -0,0 +1,50 @@
>>> +MIPS Global Interrupt Controller (GIC)
>>> +
>>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>>> +It also supports a timer and software-generated interrupts which can be
>>> +used as IPIs.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "mti,global-interrupt-controller"
>>> +- reg : Base address and length of the GIC registers.
>>> +- interrupts : Core interrupts to which the GIC may route external
>>> interrupts.
>>
>>
>> This doesn't make sense to me.  The GIC can, and does, route interrupts to
>> all CPU cores in a SMP system.  How can there be a concept of only
>> associating it with several interrupt lines on a single CPU in the system?
>> That is not what the GIC does, is it?  It is a Global interrupts controller,
>> not local.  So specifying device tree bindings that don't show its Global
>> nature seems wrong.
>
> While the GIC can route external interrupts to any HW interrupt vector
> it may not make sense to actually use all those vectors.  For example,
> the CP0 timer is usually hooked up to HW vector 5 (it could be treated
> as a GIC local interrupt, though it may still be fixed to HW vector
> 5).  BTW, the Malta example about the i8259 I gave before was wrong -
> it appears that it actually gets chained with the GIC.

Your comments don't really make sense to me in the context of my 
knowledge of the GIC.

Of course all the CP0 timer and performance counter interrupts are 
per-CPU and routed directly to the corresponding CP0_Cause[IP7..IP2] 
bits.  We are don't need to give them further consideration.


Here is the scenario you should consider:

   o 16 CPU cores.
   o 1 GIC routing interrupts from external sources to the 16 CPUs.
   o 2 network controllers each with an interrupt line routed to the GIC.

Q: What would the GIC "interrupts" property look like?

Note that the GIC doesn't have a single "interrupt-parent", as it can 
route interrupts to *all* 16 CPUs.

I propose that the GIC have neither an "interrupt-parent", nor 
"interrupts".  The fact that it is an "mti,global-interrupt-controller", 
means that the software drivers for the GIC already know how to route 
interrupts, and any information the device tree could contain is redundant.

 >
 > What would you suggest instead?  Route all GIC interrupts to a single
 > vector?

Yes.  The OCTEON interrupt controllers although architecturally 
distinct, have many of the same features as the GIC, and this is what we 
do there.  You could route the IPI interrupts to IP2, and device 
interrupts to IP3, or some similar arrangement.

But the main point is that the hardware is very flexible in how the 
interrupt signals are routed.  Somehow encoding a single simple and very 
restricted topology into the device-tree doesn't seem useful to me.

It may be the case that only certain of the CP0_Cause[IP7..IP2] bits 
should  be used by the GIC in a particular system (if they are used by 
timer or profiling hardware for example).  If that is the case, then we 
would have to have some way to specify that.  But it wouldn't be done 
via the "interrupts" property.


 >  Attempt to distribute them over all 6 vectors?

No.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/