Re: [PATCH -fixes v2 2/4] dt-bindings: riscv: Add ratified privileged ISA versions

[Stefan O'Rear]

On Thu, Feb 15, 2024, at 8:14 AM, Conor Dooley wrote:
> On Tue, Feb 13, 2024 at 03:25:44PM +0100, Andrew Jones wrote:
>> On Mon, Feb 12, 2024 at 07:37:33PM -0800, Samuel Holland wrote:
>
>> Note, QEMU doesn't add these extensions to the ISA string yet, but I think
>> it should start, particularly the profile CPU types which should ensure
>> all the profile's mandatory extensions are added to the ISA string in
>> order to avoid any confusion.
>
> Something to note about these "mandatory extensions" that are names for
> things we already assumed were present - they're utterly useless and any
> DT property should note their absence, not presence, in order to be of any
> use. Anything parsing a DT cannot see "svbare" and gain any new
> information, since the lack of it could be something that predates the
> definition of "svbare" or something without "svbare".

This is consistent with the way we handle other extensions that are assumed
at compile time - if you build with RISCV_ISA_C=y, omitting "c" from
riscv,isa-extensions will not cause an error.

It's also the case for any extension whatsoever that if that extension is
not present in the device tree, no information is provided.

It might be useful for diagnostic purposes to have a "binding version"
somewhere to indicate which extensions _would_ be documented; not sure if
there is already a mechanism for this.  For extensions that the kernel has
a hard requirement on like svbare, see above.

> Shit, but that's exactly why I deprecated riscv,isa.

If zicsr and zifencei were broken out from i today, there would not be a
problem, because i as specified by riscv,isa-extensions would refer to a
specific version that included zicsr and zifencei with a new name for the
new, smaller version of i.

It's not working here because privileged architecture versions aren't (yet)
included in riscv,isa-extensions.

-s

> Cheers,
> Conor.
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> Attachments:
> * signature.asc