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

Alex Elder elder at riscstar.com
Tue Dec 30 10:06:39 PST 2025


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

. . .

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



More information about the linux-riscv mailing list