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

[Sunil V L]

On Sat, May 13, 2023 at 01:17:03PM +0530, Anup Patel wrote:
> On Sat, May 13, 2023 at 3:35 AM Conor Dooley <conor at kernel.org> wrote:
> >
> > +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.
> 
> ISA string parsed for both DT and ACPI.
> 
> For ACPI, moving to a per-extension bit in a bitmap and defining
> a new bit with every ISA extension will be very very inconvenient
> for updating the ACPI specs. We should continue the ISA string
> parsing at least for ACPI.
> 
> For DT, users can either use "riscv,isa" DT property or use boolean
> DT properties.
> 
>From ACPI perspective, the format better be backed by unpriv (or any
other) spec from RVI considering it is a standard across OSs and to
avoid any maintenance issues.

Thanks,
Sunil