[RFC 0/6] Deprecate riscv,isa DT property?

[Conor Dooley]

+CC Greg, Mark, Krste, Philipp, Andrew,

(this is LKML now, no top posting or html replies)

On Fri, May 12, 2023 at 08:40:10PM +0100, Conor Dooley wrote:
> On Fri, May 12, 2023 at 11:01:09AM -0700, Palmer Dabbelt wrote:
> > On Thu, 11 May 2023 15:38:10 PDT (-0700), Conor Dooley wrote:
> > > On Thu, May 11, 2023 at 03:34:24PM -0700, Atish Patra wrote:
> > > > On Thu, May 11, 2023 at 2:47 PM Conor Dooley <conor at kernel.org> wrote:
> > > > > On Thu, May 11, 2023 at 02:27:44PM -0700, Atish Patra wrote:
> > > 
> > > > > That's more than last year at this point, and nothing has changed in the
> > > > > documentation! Talk's cheap, ehh?
> > > > >
> > > > 
> > > > Yup. I will poke RVI folks to check if it still is the plan or changed !!
> > > 
> > > Sounds good, thanks!
> 
> There has been some movement on that front, shall see where it goes
> :upsidedown_smile:

There's been some off-list discussion prompted by Atish with some of the
RVI spec folk, from which the upshot __appears__ to be an understanding
that using version numbering to indicate removal of ISA features is a bad
idea.
I'm hoping that this results in the enshrinement of this in the ISA
specs, so that we have something concrete to point to as the basis for
not needing to handle version numbering. 
Certainly that'd be great for ACPI and remove concerns there.

> > > > We will likely have a vendor specific string parsing logic.
> > > 
> > > Complicating the parsing logic is the exact sort of crap that I want
> > > to avoid.
> > 
> > Ya, I think we're reallly overcomplicating things with the ISA strings.
> > Let's just deprecate them and move to something that doesn't need all the
> > bespoke string parsing.
> 
> Versioning aside, although that removes a large part of the motivation,
> the interface becomes quite nice:
> of_property_present(node, "riscv,isa-extension-zicbom")

My current feeling is that, rather than introducing a key-value type of
property, adding boolean properties for extensions is the way to go
here. The "riscv,isa" part of the DT ABI pre-dates even the ratification
of the base extensions (and thus the removal of some features...).
Starting again with a new property would allow us to define extensions
as per their ratified state, rather than the intermediate & incompatible
states that we have currently got with "riscv,isa".
Such a model does rely on the strengthening of the wording in the
specification.

This had the advantage of being, as I mention above, even easier to
parse in software than the key-value pair business - but also is
trivially implemented in a dt-binding. What I have been trying to do
with the validation of the key-value stuff does not appear to be readily
doable!

(Another drawback that has come to mind is that we have no way to
validate whether mutually exclusive extensions have been added with
"riscv,isa")

> That also gives us the ability to define what supported vendor
> extensions actually mean in a dt-binding, which to me is a big win in
> terms of the aforementioned "wild west".

Vendor extensions etc are oft quoted as one of the strengths of RISC-V,
and my feeling is that "riscv,isa" is not a mechanism where we can
easily handle meanings - especially for vendor stuff where there is
otherwise no centralised location for _xfoo -> feature mappings.

Cheers,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230512/0457c13e/attachment.sig>