linux-kernel - Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger type for T-HEAD PLIC

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: <ab5b4722-8219-ab1c-e9d8-2c00e52040da@sholland.org>
Date:   Mon, 27 Jun 2022 09:14:23 -0500
From:   Samuel Holland <samuel@...lland.org>
To:     Guo Ren <guoren@...nel.org>
Cc:     Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Prabhakar <prabhakar.csengg@...il.com>,
        Marc Zyngier <maz@...nel.org>,
        Sagar Kadam <sagar.kadam@...ive.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        linux-renesas-soc@...r.kernel.org,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Thomas Gleixner <tglx@...utronix.de>,
        Biju Das <biju.das.jz@...renesas.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v1 1/3] dt-bindings: interrupt-controller: Require trigger
 type for T-HEAD PLIC

On 6/27/22 2:40 AM, Guo Ren wrote:
> On Mon, Jun 27, 2022 at 1:13 PM Samuel Holland <samuel@...lland.org> wrote:
>>
>> The RISC-V PLIC specification unfortunately allows PLIC implementations
>> to ignore edges seen while an edge-triggered interrupt is being handled:
>>
>>   Depending on the design of the device and the interrupt handler,
>>   in between sending an interrupt request and receiving notice of its
>>   handler’s completion, the gateway might either ignore additional
>>   matching edges or increment a counter of pending interrupts.
>>
>> For PLICs with that misfeature, software needs to know the trigger type
>> of each interrupt. This allows it to work around the issue by completing
>> edge-triggered interrupts before handling them. Such a workaround is
>> required to avoid missing any edges.
>>
>> The T-HEAD C9xx PLIC is an example of a PLIC with this behavior.
> Actually, C9xx support pulse signals which configed by
> pad_plic_int_cfg_x for SoC vendor:
> 
> https://github.com/T-head-Semi/openc906/blob/main/C906_RTL_FACTORY/gen_rtl/plic/rtl/plic_int_kid.v
> 104: assign int_new_pending = pad_plic_int_cfg_x ? int_pulse
> 105:
>         : level_int_pending;
> 
> They could put pad_plic_int_cfg_x into the SoC software config
> registers region or bind them to constant values.

The issue here is the "!int_active" condition for int_new_set_pending,
regardless of that configuration input.

For interrupt sources that send pulses, those pulses will be lost if they are
received while int_active is true. So the driver has to make sure int_active is
false _before_ servicing an interrupt, or it may miss the next one. This means
the driver needs to know which interrupt _sources_ send pulses and which ones
assert levels.

For level interrupts, pad_plic_int_cfg_x had better be 0, but that is a
hardware/firmware configuration concern. The driver should not have to care
about that.

(On the Allwinner D1, those inputs are memory mapped, which was the reason for
the stacked interrupt controller mentioned in my other reply. But while
pad_plic_int_cfg_x == 1 only works with edge interrupts, the pad_plic_int_cfg_x
== 0 choice works with either kind of interrupt source, so the stacked driver is
not really needed.)

Regards,
Samuel