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]
Date:   Fri, 12 Apr 2019 11:42:51 +0300
From:   Tero Kristo <t-kristo@...com>
To:     Lokesh Vutla <lokeshvutla@...com>, Tony Lindgren <tony@...mide.com>
CC:     Marc Zyngier <marc.zyngier@....com>, Nishanth Menon <nm@...com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, <jason@...edaemon.net>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>,
        Device Tree Mailing List <devicetree@...r.kernel.org>,
        Sekhar Nori <nsekhar@...com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Grygorii Strashko <grygorii.strashko@...com>
Subject: Re: [PATCH v6 06/12] dt-bindings: irqchip: Introduce TISCI Interrupt
 router bindings

On 12/04/2019 07:24, Lokesh Vutla wrote:
> 
> 
> On 11/04/19 8:30 PM, Tony Lindgren wrote:
>> Hi,
>>
>> * Lokesh Vutla <lokeshvutla@...com> [190410 04:15]:
>>> +Example:
>>> +--------
>>> +The following example demonstrates both interrupt router node and the consumer
>>> +node(main gpio) on the AM654 SoC:
>>> +
>>> +main_intr: interrupt-controller0 {
>>> +	compatible = "ti,sci-intr";
>>> +	ti,intr-trigger-type = <1>;
>>> +	interrupt-controller;
>>> +	interrupt-parent = <&gic500>;
>>> +	#interrupt-cells = <3>;
>>> +	ti,sci = <&dmsc>;
>>> +	ti,sci-dst-id = <56>;
>>> +	ti,sci-rm-range-girq = <0x1>;
>>> +};
>>
>> To me it seems there should not be too many of these interrupt
>> controller nodes for each SoC. Maybe you're already planning on
>> doing it, but I suggest that you just add more specific compatibles
>> and then look up the dst-id from a mapping table in the driver
>> similar to what patch 04/12 in this series is already doing.
>>
>> That way you don't need to add custom TI specific (firmware
>> defined) device tree properties listed above ;)
> 

< snip: I think Lokesh had a bad day or something :) >

Anyways, the reason why we want these as custom properties in the DT is 
that there are multiple instances of the routers within one SoC. On 
AM65x we have MAIN NAVSS, MCU NAVSS, GPIOs for both etc., if we add 
driver data for each of these, it easily explodes quite a bit. 
Especially going forward with new SoCs.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ