linux-kernel - Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 13 Feb 2019 07:26:20 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     Lokesh Vutla <lokeshvutla@...com>
Cc:     marc.zyngier@....com, Nishanth Menon <nm@...com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, tglx@...utronix.de,
        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>, Tero Kristo <t-kristo@...com>,
        Peter Ujfalusi <peter.ujfalusi@...com>
Subject: Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt
 router bindings

* Lokesh Vutla <lokeshvutla@...com> [190213 04:26]:
> Hi Tony,
> 
> On 12/02/19 9:52 PM, Tony Lindgren wrote:
> > Hi,
> > 
> > * Lokesh Vutla <lokeshvutla@...com> [190212 07:43]:
> >> +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";
> >> +	interrupt-controller;
> >> +	interrupt-parent = <&gic500>;
> >> +	#interrupt-cells = <4>;
> >> +	ti,sci = <&dmsc>;
> >> +	ti,sci-dst-id = <56>;
> >> +	ti,sci-rm-range-girq = <0x1>;
> >> +};
> > 
> > Can you describe a bit what the "ti,sci-dst-id" is above?
> > 
> > These IDs seem to be listed at at [0] below, but is it really a property
> > of the hardware? Or is it some enumeration of SoC devices in the firmware?
> 
> This is the way that sysfw describes the hardware. In this case it is GIC and it
> is identified by this ID.

If this ID is an enumeration in the sysfw rather than an actual
hardware property it should not be in the device tree. If so,
the device driver should request the id from the sysfw based
on a name. That is, if no struct device or device phandle can
be used.

The problem with using enumeration in the dts is that it
requires maintaining the dts, driver(s) and possibly firmware
in sync. And that might change between SoCs variants when new
devices get added and removed.

Regards,

Tony