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

On Mon, 2021-11-15 at 17:17 +0100, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> Hi Conor,
> 
> On Mon, Nov 15, 2021 at 4:39 PM <Conor.Dooley@...rochip.com> wrote:
> > On 10/11/2021 14:58, Geert Uytterhoeven wrote:
> > > 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?
> 
> If it is to be provided by the boot loader, the boot loader should
> fill
> in the interrupts property, just like it already does (or should do,
> if it
> doesn't) for /memory and chosen/bootargs.
Whether a given GPIO is routed via a bank where it has its own
interrupt line or via a bank where it shares an interrupt line is an
SoC capability.  A particular routing is instantiated by a particular
board (e.g. Icicle).  A custom bootloader feels like complete overkill
for this job.
> 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