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: <66c0676a-7920-4825-b916-3c00b1648a08@riscstar.com>
Date: Fri, 26 Dec 2025 15:28:25 -0600
From: Alex Elder <elder@...cstar.com>
To: Guodong Xu <guodong@...cstar.com>, Conor Dooley <conor@...nel.org>
Cc: 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/23/25 12:51 AM, Guodong Xu wrote:
> Hi, Conor
> 
> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@...nel.org> wrote:
>>
>> On Mon, Dec 22, 2025 at 09:04:17PM +0800, Guodong Xu wrote:
>>> Add description of the single-letter "B" extennsion for Bit Manipulation.
>>> B is mandatory for RVA23U64.
>>>
>>> The B extension is ratified in the 20240411 version of the unprivileged
>>> ISA specification. According to the ratified spec, "the B standard
>>> extension comprises instructions provided by the Zba, Zbb, and Zbs
>>> extensions.
>>>
>>> Hence add a schema check rule to enforce that B implies Zba, Zbb and Zbs.
>>>
>>> Signed-off-by: Guodong Xu <guodong@...cstar.com>
>>> ---
>>> v2: New patch.
>>> ---
>>>   .../devicetree/bindings/riscv/extensions.yaml         | 19 +++++++++++++++++++
>>>   1 file changed, 19 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> index 565cb2cbb49b552959392810a9b731b43346a594..385e1deb23996d294e7662693f1257f910a6e129 100644
>>> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
>>> @@ -109,6 +109,13 @@ properties:
>>>               The standard C extension for compressed instructions, as ratified in
>>>               the 20191213 version of the unprivileged ISA specification.
>>>
>>> +        - const: b
>>> +          description:
>>> +            The standard B extension for bit manipulation instructions, as
>>> +            ratified in the 20240411 version of the unprivileged ISA
>>> +            specification. The B standard extension comprises instructions
>>> +            provided by the Zba, Zbb, and Zbs extensions.
>>> +
>>>           - const: v
>>>             description:
>>>               The standard V extension for vector operations, as ratified
>>> @@ -735,6 +742,18 @@ properties:
>>>           then:
>>>             contains:
>>>               const: f
>>> +      # b comprises the following extensions
>>> +      - if:
>>> +          contains:
>>> +            const: b
>>
>> What's the value in adding b, if it depends on having all 3 of the
>> components defined individually too? Currently all "superset" types of
>> extensions are permitted without their component parts also being defined,
>> this doesn't follow convention and therefore needs to be explained.
>>
>> You obviously need this construct because the kernel does not understand
>> "b", and even if you added support for interpreting "b" to the kernel
>> this is probably still needed to make sure the ABI is maintained for
>> anything importing a devicetree from the kernel.
> 
> Yes, exactly. Unlike other single-letter extensions, "b" was ratified
> (Apr/2024) much later than its components zba/zbb/zbs (Jun/2021).
> Existing software and the kernel already expect these explicit component
> strings, so enforcing this dependency ensures cores declaring "b" will
> also be correctly understood by older software that only looks for
> zba/zbb/zbs.

I might be misunderstanding you, but I don't think extension "b"
should *require* the other three extensions.  Instead, the "b"
extension should be considered *equivalent* to the other three.
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".
But that might not be normal practice, and it's not necessary
because they aren't in conflict.

					-Alex

> I will update the commit message in v3 to clearly explain this reasoning.
> Does it sound good to you?
> 
> Thank you for the review.
> 
> BR,
> Guodong Xu
> 
>>
>>> +        then:
>>> +          allOf:
>>> +            - contains:
>>> +                const: zba
>>> +            - contains:
>>> +                const: zbb
>>> +            - contains:
>>> +                const: zbs
>>>         # Zcb depends on Zca
>>>         - if:
>>>             contains:
>>>
>>> --
>>> 2.43.0
>>>
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ