linux-kernel - Re: [PATCH v2 2/6] dt-bindings: interrupt-controller: add DT binding for the Marvell ICU

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: <20170608141202.14e4801e@free-electrons.com>
Date:   Thu, 8 Jun 2017 14:12:02 +0200
From:   Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        Pawel Moll <pawel.moll@....com>,
        Mark Rutland <mark.rutland@....com>,
        Kumar Gala <galak@...eaurora.org>,
        Andrew Lunn <andrew@...n.ch>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Gregory Clement <gregory.clement@...e-electrons.com>,
        Nadav Haklai <nadavh@...vell.com>,
        Hanna Hawa <hannah@...vell.com>,
        Yehuda Yitschak <yehuday@...vell.com>,
        Antoine Tenart <antoine.tenart@...e-electrons.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/6] dt-bindings: interrupt-controller: add DT
 binding for the Marvell ICU

Hello,

On Wed, 7 Jun 2017 17:33:17 -0500, Rob Herring wrote:

> > +Example:
> > +
> > +icu: interrupt-controller@...000 {
> > +	compatible = "marvell,cp110-icu";
> > +	reg = <0x1e0000 0x10>;
> > +	#interrupt-cells = <3>;
> > +	interrupt-controller;
> > +	interrupt-parent = <&gic>;  
> 
> If you have a parent, then you should have some interrupts. I guess that 
> would be your ranges property? I suppose that is fine.

The ranges of interrupts available is defined by the gicp node. Indeed,
as explained in the cover letter:

 - We have one GICP in the SoC, providing a number of GIC SPI interrupts

 - We have one ICU per CP in the SoC. So for example in the Armada 8K,
   we have two CPs, and therefore two ICUs.

So the range of available GIC SPI interrupts it not associated to each
ICU, it's a global range of GIC SPI interrupts: each can freely be
allocated by any of the ICUs in the system.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com