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@riscstar.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
+        then:
+          allOf:
+            - contains:
+                const: zba
+            - contains:
+                const: zbb
+            - contains:
+                const: zbs
       # Zcb depends on Zca
       - if:
           contains:

-- 
2.43.0

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@riscstar.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.

> +        then:
> +          allOf:
> +            - contains:
> +                const: zba
> +            - contains:
> +                const: zbb
> +            - contains:
> +                const: zbs
>        # Zcb depends on Zca
>        - if:
>            contains:
> 
> -- 
> 2.43.0
> 

Hi, Conor

On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.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
> >

On 12/23/25 12:51 AM, Guodong Xu wrote:
> Hi, Conor
> 
> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.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
>>>
> 

On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
> On 12/23/25 12:51 AM, Guodong Xu wrote:
> > Hi, Conor
> > 
> > On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.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.

The dependency can be go both ways, to also make specifying "b" mandatory
when the three components are. That probably produces the most helpful
devicetree ultimately.

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

I disagree completely with this "even further", since that's potentially
actively harmful to importers of kernel devicetrees.
If "b" is to be allowed, I'm only in favour if having it requires the
component parts.

On 12/30/25 11:09 AM, Conor Dooley wrote:
> On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
>> On 12/23/25 12:51 AM, Guodong Xu wrote:
>>> Hi, Conor
>>>
>>> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.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.
> 
> The dependency can be go both ways, to also make specifying "b" mandatory
> when the three components are. That probably produces the most helpful
> devicetree ultimately.

What about DT files that specified zba+zbb+zbs before "b" was
ratified?

>> 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.
> 
> I disagree completely with this "even further", since that's potentially
> actively harmful to importers of kernel devicetrees.

This is related to one of the things I mentioned to Rob that I
wanted to discuss.

This type of "equivalent" extension is problematic for DT, or I
guess, it doesn't really add any value.  I'm sure the people
ratifying "b" to be equivalent to "zba+zbb+zbs" intend for it
to simplify how the supported extensions are represented.

But it actually complicates things for DT.  If you're going
to support just "b" (which would be simpler and more concise)
then there needs to be logic that treats the two possibilities
as equivalent.  But old software won't recognize new DT files
that contain only the newer (e.g. "b") extension.

So I agree, there's active harm in doing what I suggested.

But why even bother supporting "b" if you have to *also*
support "zba+zbb+zbs" if you use it?  It adds the possibility
of new errors ("b" without "zbs", for example), while not
really enabling or representing anything new.

> If "b" is to be allowed, I'm only in favour if having it requires the
> component parts.

I'd opt for ignoring the "b" extension, and any other
"simplified" extensions that simply represent a specific
set of other extensions and nothing more.  At least for DT.

That said, this "rule" would have to be followed/agreed to
by all users of DT.

					-Alex

On Tue, Dec 30, 2025 at 11:29:14AM -0600, Alex Elder wrote:
> On 12/30/25 11:09 AM, Conor Dooley wrote:
> > On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
> > > On 12/23/25 12:51 AM, Guodong Xu wrote:
> > > > Hi, Conor
> > > > 
> > > > On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.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.
> > 
> > The dependency can be go both ways, to also make specifying "b" mandatory
> > when the three components are. That probably produces the most helpful
> > devicetree ultimately.
> 
> What about DT files that specified zba+zbb+zbs before "b" was
> ratified?

They'd generate a warning, which can then be fixed. That's fine to do, a
warning in linux-next doesn't harm anyone. Updating devicetrees in ways
that don't change their meaning but provide extra value is not a problem
in my book.

> > > 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.
> > 
> > I disagree completely with this "even further", since that's potentially
> > actively harmful to importers of kernel devicetrees.
> 
> This is related to one of the things I mentioned to Rob that I
> wanted to discuss.
> 
> This type of "equivalent" extension is problematic for DT, or I
> guess, it doesn't really add any value.  I'm sure the people
> ratifying "b" to be equivalent to "zba+zbb+zbs" intend for it
> to simplify how the supported extensions are represented.
> 
> But it actually complicates things for DT.  If you're going
> to support just "b" (which would be simpler and more concise)
> then there needs to be logic that treats the two possibilities
> as equivalent.  But old software won't recognize new DT files
> that contain only the newer (e.g. "b") extension.
> 
> So I agree, there's active harm in doing what I suggested.

> But why even bother supporting "b" if you have to *also*
> support "zba+zbb+zbs" if you use it?  It adds the possibility
> of new errors ("b" without "zbs", for example), while not
> really enabling or representing anything new.

That was my first question after all! Ultimately I'd really err on the
side of adding it because people will expect to be able to use it and
because, in terms of kernel support, it will be useful for ACPI systems.

On 12/30/25 11:46 AM, Conor Dooley wrote:
> On Tue, Dec 30, 2025 at 11:29:14AM -0600, Alex Elder wrote:
>> On 12/30/25 11:09 AM, Conor Dooley wrote:
>>> On Fri, Dec 26, 2025 at 03:28:25PM -0600, Alex Elder wrote:
>>>> On 12/23/25 12:51 AM, Guodong Xu wrote:
>>>>> Hi, Conor
>>>>>
>>>>> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.com>
>>>>>>> ---

. . .

>>> The dependency can be go both ways, to also make specifying "b" mandatory
>>> when the three components are. That probably produces the most helpful
>>> devicetree ultimately.
>>
>> What about DT files that specified zba+zbb+zbs before "b" was
>> ratified?
> 
> They'd generate a warning, which can then be fixed. That's fine to do, a
> warning in linux-next doesn't harm anyone. Updating devicetrees in ways
> that don't change their meaning but provide extra value is not a problem
> in my book.

OK.

. . .

>> But why even bother supporting "b" if you have to *also*
>> support "zba+zbb+zbs" if you use it?  It adds the possibility
>> of new errors ("b" without "zbs", for example), while not
>> really enabling or representing anything new.
> 
> That was my first question after all! Ultimately I'd really err on the
> side of adding it because people will expect to be able to use it and
> because, in terms of kernel support, it will be useful for ACPI systems.

I think it's too bad these "equivalent" extensions can't be used
to simplify things.

I really dislike requiring the both a simpler extension *and*
the others that it represents/implies.

But practically speaking you're probably right.  People will
expect to be able to use them.  DT tools will then point out
what's missing, and the list of extensions supported by a
given CPU will just grow and grow and grow.

					-Alex

On Tue, Dec 30, 2025 at 12:06:39PM -0600, Alex Elder wrote:


> I think it's too bad these "equivalent" extensions can't be used
> to simplify things.
> 
> I really dislike requiring the both a simpler extension *and*
> the others that it represents/implies.

They generally have been done they way you'd expect, this one just
differs because b is being added much later on rather than at the same
time.

Hi, Alex

On Sat, Dec 27, 2025 at 5:28 AM Alex Elder <elder@riscstar.com> wrote:
>
> On 12/23/25 12:51 AM, Guodong Xu wrote:
> > Hi, Conor
> >
> > On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.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.

You are correct in saying they are equivalent.

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

BR,
Guodong

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

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

On Mon, Dec 29, 2025 at 7:50 AM Alex Elder <elder@riscstar.com> wrote:
>
> 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?


The risc-v ratification timeline is:
"b" was ratified in Apr/2024, which is about 2 years later than its
components zba/zbb/zbs (these were ratified in Jun/2021).

I can do this in linux kernel, writing a dts file which contains only "b",
but no zba/zbb/zbs. The linux kernel can correctly extend "b" to zba/zbb/zbs.
ps: after I or somebody adds the logic into cpufeature.c.

However, the problem is with the older software who reuse kernel's DTS files,
and recognizes only 'zba/zbb/zbs'. (If you search in the riscv/boot/dts,
you will notice a lot platforms supports zba/zbb/zbs.)

When there is only "b", these older software may just disable the features
related to 'zba/zbb/zbs', because when they developed their feature,
"b" doesn't exist yet.

Hopefully I explained the logic clear this time.

BR,
Guodong

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

On 12/28/25 7:08 PM, Guodong Xu wrote:
> On Mon, Dec 29, 2025 at 7:50 AM Alex Elder <elder@riscstar.com> wrote:
>>
>> 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?
> 
> 
> The risc-v ratification timeline is:
> "b" was ratified in Apr/2024, which is about 2 years later than its
> components zba/zbb/zbs (these were ratified in Jun/2021).
> 
> I can do this in linux kernel, writing a dts file which contains only "b",
> but no zba/zbb/zbs. The linux kernel can correctly extend "b" to zba/zbb/zbs.
> ps: after I or somebody adds the logic into cpufeature.c.

Yes, this part I understand.  (Yes, do that...)

> However, the problem is with the older software who reuse kernel's DTS files,
> and recognizes only 'zba/zbb/zbs'. (If you search in the riscv/boot/dts,
> you will notice a lot platforms supports zba/zbb/zbs.)
> 
> When there is only "b", these older software may just disable the features
> related to 'zba/zbb/zbs', because when they developed their feature,
> "b" doesn't exist yet.

Yes, old DTS files can and will continue to specify
"zba+zbb+zbs".  But those old DTS files are not expected
to be changed to replace "zba+zbb+zbs" with just "h".

Once "cpufeature.c" supports the "h" extension, the
software supports either one:  "h" or "zba+zbb+zbs".

The key point I'm trying to make is that the binding
should not require "zba+zbb+zbs" to supplied *on top of*
the "h" in the list of CPU extensions.  Only one or the
other should be sufficient.  And I think your binding
was saying "if "h" then required "zba+zbb+zbs".

> Hopefully I explained the logic clear this time.

I think you have done your best.  I hope I'm not just being
dense.

					-Alex

> BR,
> Guodong
> 
>>
>> 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

On Tue, Dec 23, 2025 at 02:51:17PM +0800, Guodong Xu wrote:
> Hi, Conor
> 
> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor@kernel.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@riscstar.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?

Ye, sounds good.