linux-kernel - Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description

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: <5979c8ef-b0fa-40c8-944d-96e226fbcbe8@riscstar.com>
Date: Sun, 28 Dec 2025 17:50:14 -0600
From: Alex Elder <elder@...cstar.com>
To: Guodong Xu <guodong@...cstar.com>
Cc: Conor Dooley <conor@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Paul Walmsley <pjw@...nel.org>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>, Yixun Lan <dlan@...too.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>,
 Thomas Gleixner <tglx@...utronix.de>,
 Samuel Holland <samuel.holland@...ive.com>, Anup Patel
 <anup@...infault.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jiri Slaby <jirislaby@...nel.org>, Lubomir Rintel <lkundrak@...sk>,
 Yangyu Chen <cyy@...self.name>, Paul Walmsley <paul.walmsley@...ive.com>,
 Heinrich Schuchardt <xypron.glpk@....de>,
 Kevin Meng Zhang <zhangmeng.kevin@...ux.spacemit.com>,
 Andrew Jones <ajones@...tanamicro.com>, devicetree@...r.kernel.org,
 linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
 spacemit@...ts.linux.dev, linux-serial@...r.kernel.org
Subject: Re: [PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension
 description

On 12/27/25 8:51 PM, Guodong Xu wrote:
>> That's what I understand it to mean, anyway.
>>     https://github.com/riscv/riscv-b
>>
>> There's no point in supporting "b" in devicetree to represent
>> the others if it also requires the others to be present.
>>
>> I think that, instead, "b", "zba", "zbb", and "zbs" should all
>> be allowed.
>>
>> I might even go further and harden the requirement, saying that
>> if you specify "b" you should*not* specify "zba", "zbb", or "zbs".
> Historical reasons here. "b" came too late. The chip vendors have published
> cores with "zba", "zbb", and "zbs"already.
> 
> That's a migration bridge to require "b" must be listed
> together with the other three.

Are you saying "b" has already been included with "zba", "zbb", and
"zbs" in an existing DTS file?

What I'm suggesting is that (unless someone has already done this in
a DTS file), there is no reason to require "b" *and* the other three.
You should allow either "b" *or* all of the other three, not both.
That would support older platforms as well as newer ones that use
the more concise "b" only.

					-Alex