linux-kernel - Re: [patches] Re: [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings

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, 20 Nov 2017 11:45:32 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     j.neuschaefer@....net, Mark Rutland <mark.rutland@....com>
CC:     patches@...ups.riscv.org, Arnd Bergmann <arnd@...db.de>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Olof Johansson <olof@...om.net>, linux-kernel@...r.kernel.org,
        robh+dt@...nel.org, albert@...ive.com,
        yamada.masahiro@...ionext.com, mmarek@...e.com,
        Will Deacon <will.deacon@....com>, peterz@...radead.org,
        boqun.feng@...il.com, oleg@...hat.com, mingo@...hat.com,
        devicetree@...r.kernel.org, rminnich@...il.com
Subject:     Re: [patches] Re: [PATCH v9 03/12] dt-bindings: RISC-V CPU Bindings

On Sun, 19 Nov 2017 23:35:28 PST (-0800), j.neuschaefer@....net wrote:
> Hi Palmer,
>
> On Thu, Oct 05, 2017 at 11:16:33AM +0100, Mark Rutland wrote:
> [...]
>> I would *strongly* recommend that from day one, you determine the SMP
>> bringup mechanism via an enable-method property, and document the
>> contract with FW/bootloader somewhere in the kernel tree.

Sorry, I forgot about this.  I've prepared a patch.

> Somewhat, but not quite related: Please consider making the availability
> of the Supervisor Binary Interface explicit in the devicetree.
> I understand that the general plan is to make the SBI a mandatory
> feature of every RISC-V system capable of running Linux, but I do want
> to explore the possibility of running without run-time resident firmware
> at some point in the future. Thus it would be nice if the devicetree
> would indicate the presence of the SBI from the start, to avoid having
> to invent a way to express its *absence* later on.
>
> It could look something like this (modelled after qcom,scm):
>
> / {
> 	firmware {
> 		sbi {
> 			compatible = "riscv,sbi";
> 		};
> 	};
> };
>
> This topic may warrant some discussion, because other people may have
> different opinions, and there hasn't been a discussion about it, AFAICS.

I don't think there's any penalty to putting it in the device tree, I'll send a 
patch.