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

[Alex Elder]

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@xxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > > > > > ---

. . .

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