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

[Alex Elder]

On 12/28/25 7:08 PM, Guodong Xu wrote:
> On Mon, Dec 29, 2025 at 7:50 AM Alex Elder <elder at 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