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] [day] [month] [year] [list]
Date:   Mon, 30 Nov 2020 08:36:06 -0700
From:   Rob Herring <robh@...nel.org>
To:     Yash Shah <yash.shah@...nfive.com>
Cc:     "Paul Walmsley ( Sifive)" <paul.walmsley@...ive.com>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
        "Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
        "wsa@...nel.org" <wsa@...nel.org>,
        "sam@...nborg.org" <sam@...nborg.org>,
        Sagar Kadam <sagar.kadam@...nfive.com>,
        "anup@...infault.org" <anup@...infault.org>,
        "bp@...e.de" <bp@...e.de>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Sachin Ghadi <sachin.ghadi@...nfive.com>
Subject: Re: [PATCH 1/2] RISC-V: Update l2 cache DT documentation to add
 support for SiFive FU740

On Mon, Nov 23, 2020 at 3:32 AM Yash Shah <yash.shah@...nfive.com> wrote:
>
> > -----Original Message-----
> > From: Rob Herring <robh@...nel.org>
> > Sent: 21 November 2020 18:25
> > To: Yash Shah <yash.shah@...nfive.com>
> > Cc: Paul Walmsley ( Sifive) <paul.walmsley@...ive.com>;
> > palmer@...belt.com; aou@...s.berkeley.edu;
> > Jonathan.Cameron@...wei.com; wsa@...nel.org; sam@...nborg.org;
> > Sagar Kadam <sagar.kadam@...nfive.com>; anup@...infault.org;
> > bp@...e.de; devicetree@...r.kernel.org; linux-riscv@...ts.infradead.org;
> > linux-kernel@...r.kernel.org; Sachin Ghadi <sachin.ghadi@...nfive.com>
> > Subject: Re: [PATCH 1/2] RISC-V: Update l2 cache DT documentation to add
> > support for SiFive FU740
> >
> > [External Email] Do not click links or attachments unless you recognize the
> > sender and know the content is safe
> >
> > On Thu, Nov 12, 2020 at 02:41:13PM +0530, Yash Shah wrote:
> > > The L2 cache controller in SiFive FU740 has 4 ECC interrupt sources as
> > > compared to 3 in FU540. Update the DT documentation accordingly with
> > > "compatible" and "interrupt" property changes.
> > >
> > > Signed-off-by: Yash Shah <yash.shah@...ive.com>
> > > ---
> > >  .../devicetree/bindings/riscv/sifive-l2-cache.yaml | 33
> > > +++++++++++++++++-----
> > >  1 file changed, 26 insertions(+), 7 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> > > b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> > > index efc0198..4873d5c 100644
> > > --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml
>
> <...>
>
> > > @@ -51,12 +54,6 @@ properties:
> > >
> > >    cache-unified: true
> > >
> > > -  interrupts:
> > > -    description: |
> > > -      Must contain entries for DirError, DataError and DataFail signals.
> > > -    minItems: 3
> > > -    maxItems: 3
> >
> > Keep this here and just change maxItems to 4. Really, what each interrupt is
> > should be listed out as an 'items' entry.
> >
>
> Sure will send a v2 with the above modifications.
>
> <...>
>
> >
> > > +
> > > +else:
> > > +  properties:
> > > +    interrupts:
> > > +      description: |
> > > +        Must contain entries for DirError, DirFail, DataError, DataFail signals.
> >
> > DirFail should be last so you keep the same indices.
>
> Actually, the interrupts have been numbered like that in FU740 SoCs and the driver expects the interrupts to be in this order.
> I will keep the same order for v2 as well. Let me know if you still disagree.

Numbered within the cache block or the interrupt controller? If the
former, then fine. The latter would be outside the scope of the
binding. Another SoC could hook up interrupts differently.

It's going to be easier for the driver to deal with 1 new irq index
rather than 2 whole sets of different indices, but if you want to do
it the hard way...

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ