[PATCH v2 07/13] dt-bindings: riscv: Add B ISA extension description
Alex Elder
elder at riscstar.com
Fri Dec 26 13:28:25 PST 2025
On 12/23/25 12:51 AM, Guodong Xu wrote:
> Hi, Conor
>
> On Tue, Dec 23, 2025 at 5:17 AM Conor Dooley <conor at 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 at 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
>>>
>
More information about the linux-riscv
mailing list