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: <5b5d86b9-2aa7-718c-c1da-70bbf9bf589e@ti.com>
Date:   Wed, 13 Feb 2019 09:52:51 +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 12/02/19 10:00 PM, Tony Lindgren wrote:
> Hi,
> 
> * Lokesh Vutla <lokeshvutla@...com> [190212 07:43]:
>> +The Interrupt Router (INTR) module provides a mechanism to route M
>> +interrupt inputs to N interrupt outputs, where all M inputs are selectable
>> +to be driven per N output. There is one register per output (MUXCNTL_N) that
>> +controls the selection.
>> +
>> +
>> +                                 Interrupt Router
>> +                             +----------------------+
>> +                             |  Inputs     Outputs  |
>> +        +-------+            | +------+             |
>> +        | GPIO  |----------->| | irq0 |             |       Host IRQ
>> +        +-------+            | +------+             |      controller
>> +                             |    .        +-----+  |      +-------+
>> +        +-------+            |    .        |  0  |  |----->|  IRQ  |
>> +        | INTA  |----------->|    .        +-----+  |      +-------+
>> +        +-------+            |    .          .      |
>> +                             | +------+      .      |
>> +                             | | irqM |    +-----+  |
>> +                             | +------+    |  N  |  |
>> +                             |             +-----+  |
>> +                             +----------------------+
> 
> Is this always one-to-one mapping or can the same interrupt be routed to
> multiple targets like to the SoC and some coprocessor?

Yes, it is always one-to-one. Output of INTR can only be attached to one of the
processor.

> 
>> +Configuration of these MUXCNTL_N registers is done by a system controller
>> +(like the Device Memory and Security Controller on K3 AM654 SoC). System
>> +controller will keep track of the used and unused registers within the Router.
>> +Driver should request the system controller to get the range of GIC IRQs
>> +assigned to the requesting hosts. It is the drivers responsibility to keep
>> +track of Host IRQs.
>> +
>> +Communication between the host processor running an OS and the system
>> +controller happens through a protocol called TI System Control Interface
>> +(TISCI protocol). For more details refer:
>> +Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> 
> Care to describe a bit why the interrupts need to be routed by a system
> controller?

K3 architecture defines a heterogeneous system where multiple heterogeneous
cores are serving its own usecases. Given that there are multiple ways in which
a device IRQ can be routed using INTR, like either it can be routed to HLOS
core(A53 int this case) or it can be routed to any other coprocessor available
in the system(like R5). If every sw running in each co-processor is allowed to
program this INTR then there is a high probability that one sw executing on one
core can damage other heterogeneous core.  Mainly to avoid this damage the
configuration of all the INTRs and INTAs are done in a centralized place(sysfw).
Any user for programming its IRQ route should send a message to sysfw with the
parameters. These parameters are policed by sysfw and does the configuration.


Thanks and regards,
Lokesh