linux-kernel - Re: [PATCH v5 1/3] dt-bindings: interrupt-controller: Add Actions SIRQ controller binding

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: <7de137f820d5a3b7921bda0751509f85@kernel.org>
Date:   Thu, 27 Aug 2020 16:42:04 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Cristian Ciocaltea <cristian.ciocaltea@...il.com>
Cc:     Rob Herring <robh@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Andreas Färber <afaerber@...e.de>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        linux-actions@...ts.infradead.org
Subject: Re: [PATCH v5 1/3] dt-bindings: interrupt-controller: Add Actions
 SIRQ controller binding

Cristian,

On 2020-08-27 16:24, Cristian Ciocaltea wrote:
> Hi Marc,
> 
> On Thu, Aug 27, 2020 at 11:35:06AM +0100, Marc Zyngier wrote:
>> On 2020-08-27 11:06, Cristian Ciocaltea wrote:
>> > On Wed, Aug 26, 2020 at 04:48:38PM -0600, Rob Herring wrote:
>> > > On Wed, Aug 26, 2020 at 3:42 PM Cristian Ciocaltea
>> > > <cristian.ciocaltea@...il.com> wrote:
>> 
>> [...]
>> 
>> > > Ultimately the GIC trigger type has to be
>> > > something. Is it fixed or passed thru? If the latter, just use 0
>> > > (IRQ_TYPE_NONE) if the GIC trigger mode is not fixed. Having some sort
>> > > of translation of the trigger is pretty common.
>> >
>> > Yes, as explained above, the SIRQ controller performs indeed the
>> > translation of the incoming signal. So if I understand correctly, your
>> > suggestion would be to use the following inside the sirq node:
>> >
>> > interrupts = <GIC_SPI 13 IRQ_TYPE_NONE>, /* SIRQ0 */
>> >              [...]
>> 
>> Please don't. If you are describing a GIC interrupt, use a
>> trigger that actually exists. Given that you have a 1:1
>> mapping between input and output, just encode the output
>> trigger that matches the input.
> 
> Understood, the only remark here is that internally, the driver will
> not use this information and instead will continue to rely on the input
> to properly set the trigger type for the output.

It's fine. The binding has to be consistent on its own, but
doesn't dictate the way the driver does thing.

> The question is if the driver should also emit a warning (or error?)
> when the trigger type supplied via DT doesn't match the expected value.

Rob will tell you that the kernel isn't a validation tool for broken
DTs. Shout if you want, but you are allowed to simply ignore the
output trigger for example

> If yes, we should also clarify what the user is supposed to provide in
> the controller node: the trigger type before the conversion (the input)
> or the one after the conversion (the output).

The output of a SIRQ should be compatible with the GIC input it is
attached to. You can have:

         device (LEVEL_LOW) -> SIRQ (LEVEL_HIGH) -> GIC

but you can't have:

         device (LEVEL_LOW) -> SIRQ (EDGE_RISING) -> GIC

because that's not an acceptable transformation for the SIRQ,
nor can you have:

         device (EDGE_FALLING) -> SIRQ (EDGE_FALLING) -> GIC

because EDGE_FALLING isn't a valid input for the GIC.

In both of the invalid cases, you would be free to apply
which ever transformation actually makes sense, and shout
at the user if you want to help them debugging their turf.
The later part is definitely optional.

Hope this helps,

         M.
-- 
Jazz is not dead. It just smells funny...