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