linux-kernel - Re: [RFC] irqchip: add support for LS1021A external interrupt lines

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: <62c4af0c-ffe5-23c9-9ef6-2e4b8ab90050@prevas.dk>
Date:   Fri, 15 Dec 2017 23:55:34 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Rob Herring <robh@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Stein <alexander.stein@...tec-electronic.com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [RFC] irqchip: add support for LS1021A external interrupt lines

On 2017-12-13 00:28, Rob Herring wrote:
> On Fri, Dec 08, 2017 at 03:33:00PM +0100, Rasmus Villemoes wrote:
>>
>>  .../interrupt-controller/fsl,ls1021a-extirq.txt    |  19 +++
> 
> Please split to separate patch.

Will do.

>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls1021a-extirq.txt
>> @@ -0,0 +1,19 @@
>> +* Freescale LS1021A external IRQs
>> +
>> +The LS1021A supports inverting the polarity of six external interrupt lines.
>> +
>> +Required properties:
>> +- compatible: should be "fsl,ls1021a-extirq"
>> +- interrupt-controller: Identifies the node as an interrupt controller
>> +- #interrupt-cells: Use the same format as specified by GIC in arm,gic.txt.
>> +- interrupt-parent: phandle of GIC.
>> +- syscon: phandle of Supplemental Configuration Unit (scfg).
> 
> Can this be a child of that node instead?

I suppose it could, but I don't think it would make much sense. In any
case, I did it this way because that seemed to be the way the syscon
driver is used in lots of other cases, cf. all the occurrences of
syscon_regmap_lookup_by_phandle() and the corresponding bindings - I
don't think I've seen any of those cases represent the syscon-using node
as a child of the syscon node.

>> +
>> +Example:
>> +		extirq: interrupt-controller@...01ac {
> 
> Unit-address without reg is not valid. Building with W=1 will tell you 
> this.

Thanks, that was actually a leftover from an earlier version.

Rasmus