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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <84b3ec21-9ce9-b9a8-80a9-75001db43a90@ti.com>
Date:   Tue, 19 Feb 2019 14:21:10 +0530
From:   Lokesh Vutla <lokeshvutla@...com>
To:     Tony Lindgren <tony@...mide.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

Hi Tony,

On 18/02/19 8:02 PM, Tony Lindgren wrote:
> * Lokesh Vutla <lokeshvutla@...com> [190216 03:30]:
>> On 2/15/2019 9:46 PM, Tony Lindgren wrote:
>>> The dts node for the interrupt controller should describe a
>>> proper Linux device, that is with reg entries and so on.
>>
>> You are asking to just keep the compatible property :)
> 
> Right, and then I realized this node is missing the standard
> reg entry too. And you're saying the registers are not even
> accissible from Linux.
> 
> So based on that IMO you should not even have a device tree
> node for it at all. You should just have the interrupt

Practically lets look at what all I am adding in the DT node. Below is one such
example:

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>;
};

The following 4 properties are required at least for probing, to represent the
hierarchy and for  interrupt definition:
	compatible = "ti,sci-intr";
	interrupt-controller;
	interrupt-parent = <&gic500>;
	#interrupt-cells = <4>;

The remaining 3 properties represents the TISCI interface. Let's go step by step:
* ti,sci = <&dmsc> :This is the phandle to the firmware protocol driver using
which the messages are sent
* ti,sci-dst-id = <56> : This is the TISCI device ID for the parent controller
for which your irqs needs to be connected. As I said this cannot be queried from
sysfw and this is the input to the messages that are send to sysfw.
*  ti,sci-rm-range-girq = <0x1>: This define the ids using which the parent-irq
ranges that are allocated to this interrupt router instance can be queried from
sysfw.
If the above 2 properties are to be added as driver phandle then for every
instance of interrupt router in the SoC, a new compatible needs to be created. I
don't think this is a desirable solution.

With this can you tell me how can we not have a device-tree and still support
irq allocation?

Also, this is not the first time a driver based on a firmware is being added.
K2g clock, power and reset drivers are based on this where device ids are being
passed from consumers. Similarly arm scpi based drivers are also available.

Thanks and regards,
Lokesh