On 13 May 2023, at 08:47, Anup Patel <apatel@xxxxxxxxxxxxxxxx> 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. Can we please not gratuitously have two ways of doing the same thing. I say this as a non-Linux OS that has to deal with whatever Linux decides to do with device trees. It is a total nuisance when you flip flop on things and we have to follow suit. Please consider the breakage very carefully. Jess >> 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. > > Regards, > Anup > > _______________________________________________ > linux-riscv mailing list > linux-riscv@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-riscv
