linux-kernel - Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node

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:   Tue, 21 Nov 2017 10:43:57 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Palmer Dabbelt <palmer@...ive.com>
Cc:     j.neuschaefer@....net, robh+dt@...nel.org,
        devicetree@...r.kernel.org, patches@...ups.riscv.org,
        linux-kernel@...r.kernel.org
Subject: Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node

Hi Palmer,

On Mon, Nov 20, 2017 at 01:28:01PM -0800, Palmer Dabbelt wrote:
> On Mon, 20 Nov 2017 12:28:56 PST (-0800), j.neuschaefer@....net wrote:
> > On Mon, Nov 20, 2017 at 11:50:00AM -0800, Palmer Dabbelt wrote:
> > > +RISC-V Supervisor Binary Interface (SBI)
> > > +
> > > +The RISC-V privileged ISA specification mandates the presence of a supervisor
> > > +binary interface that performs some operations which might otherwise require
> > > +particularly complicated instructions.  This interface includes
> > > +inter-processor interrupts, TLB flushes, i-cache and TLB shootdowns, a
> > > +console, and power management.
> > > +
> > > +Required properties:
> > > +- compatible: must contain one of the following
> > > + * "riscv,sbi" for the SBI defined by the privileged specification of the
> > > +   system.
> > 
> > "of the system" seems to imply that different RISC-V systems (different
> > RISC-V implementations) can have different privileged specifications.
> 
> Actually, that was intentional -- I wrote it this way because different
> RISC-V systems do have different privileged specifications.  The RISC-V
> specifications aren't frozen in time, they're just guaranteed to be
> compatible in the future. 

If that's the case, then you can define a version of the document that
is a baseline. e.g. 

 * "riscv,sbi" for an SBI implementation compatible with that defined
   in $XYZ_DOCUMENT version $N

If every new feature can be probed from that point onwards, then that's
all you'll ever need. Otherwise, if there are backwards-incompatible
changes or non-probeable features, you can add additional strings, and
there's no ambiguity.

See Documentation/devicetree/bindings/arm/psci.txt for an similar
example on ARM systems. That's explicitly versioned, though we don't
list each and every document number, and we probably should.

Thanks,
Mark.