linux-kernel - Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit device tree

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]

Date:   Mon, 15 Nov 2021 15:39:11 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <geert@...ux-m68k.org>
CC:     <linus.walleij@...aro.org>, <bgolaszewski@...libre.com>,
        <robh+dt@...nel.org>, <jassisinghbrar@...il.com>,
        <paul.walmsley@...ive.com>, <palmer@...belt.com>,
        <aou@...s.berkeley.edu>, <a.zummo@...ertech.it>,
        <alexandre.belloni@...tlin.com>, <broonie@...nel.org>,
        <gregkh@...uxfoundation.org>, <Lewis.Hanly@...rochip.com>,
        <Daire.McNamara@...rochip.com>, <atish.patra@....com>,
        <Ivan.Griffin@...rochip.com>, <linux-gpio@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-i2c@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
        <linux-crypto@...r.kernel.org>, <linux-rtc@...r.kernel.org>,
        <linux-spi@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <krzysztof.kozlowski@...onical.com>, <bin.meng@...driver.com>
Subject: Re: [PATCH 12/13] riscv: icicle-kit: update microchip icicle kit
 device tree

On 10/11/2021 14:58, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Conor,
> 
> On Wed, Nov 10, 2021 at 3:20 PM <Conor.Dooley@...rochip.com> wrote:
>> On 09/11/2021 09:04, Geert Uytterhoeven wrote:
>>> On Mon, Nov 8, 2021 at 4:07 PM <conor.dooley@...rochip.com> wrote:
>>>> From: Conor Dooley <conor.dooley@...rochip.com>
>>>>
>>>> +&gpio2 {
>>>> +       interrupts = <PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT
>>>> +               PLIC_INT_GPIO2_NON_DIRECT>;
>>>
>>> Why override interrupts in the board .dts file?
>>> Doesn't this belong in the SoC .dtsi file?
>> The interrupt setup for the gpio isnt fixed, there is an option to
>> either connect the individual gpio interrupts to the plic *or* they can
>> be connected to a per gpio controller common interrupt, and it is up to
>> the driver to read a register to determine which interrupt triggered the
>> common/NON_DIRECT interrupt. This decision is made by a write to a
>> system register in application code, which to us didn't seem like it
>> belonged in the soc .dtsi.
> 
> So it is software policy? Then it doesn't belong in the board DTS either.
The write (if was to be done) would be done by the bootloader, based on 
the bitstream written to the FPGA, before even u-boot is started. By 
application I meant the bootloader (or some other bare metal 
application), not a program running in userspace in case that's what you 
interpreted. Am I incorrect in thinking that if it is set up by the 
bootloader that Linux can take it for granted?
> 
>> Using the common interrupt for GPIO2 is the default on the
>> polarfire-soc, there are only 38 per gpio line interrupts available of
>> which 14 are connected to gpio0 and 24 to gpio1.
> 
> 
> Exactly.
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds
>