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] [day] [month] [year] [list]

Date:   Tue, 21 Nov 2017 16:36:22 -0800 (PST)
From:   Palmer Dabbelt <palmer@...ive.com>
To:     j.neuschaefer@....net
CC:     robh@...nel.org, j.neuschaefer@....net, mark.rutland@....com,
        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

On Tue, 21 Nov 2017 12:08:32 PST (-0800), j.neuschaefer@....net wrote:
> On Tue, Nov 21, 2017 at 09:37:02AM -0800, Palmer Dabbelt wrote:
> [...]
>> This isn't really a big deal to me, as I'm only interested in RISC-V
>> systems, but there's been some pushback on the concept of an SBI so it
>> seemed like a simple way to allow people to build non-SBI (and there for not
>> really RISC-V) systems.
>
> For those reading along: I suggested the /firmware/sbi node to Palmer,
> because I'm interested in such "not really RISC-V" systems, (because it
> makes the firmware's job easier to not implement the SBI — speaking with
> my coreboot hat, here.)
>
>> One option that wouldn't require a device tree node
>> would be to have Linux boot in machine mode [...] and then provide its
>> own SBI implementation.
>
> I think this can work.

OK, sounds good!