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

[Jessica Clarke]

On 13 May 2023, at 08:47, Anup Patel <apatel at ventanamicro.com> 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.

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv