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

Message-ID: <CAH1PCMZ7ywZ3unLy0yHYK+fFHk0y=q2cEtPnRi=qSpf=fc75rw@mail.gmail.com>
Date: Tue, 23 Dec 2025 14:51:17 +0800
From: Guodong Xu <guodong@...cstar.com>
To: 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

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 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
> >