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

[Conor Dooley]

On Thu, May 11, 2023 at 02:27:44PM -0700, Atish Patra wrote:

> > The other thought I had was that perhaps some software may choose not to
> > implement version x.y.0 of an extension and only support x.z.0, z > y
> > for some reason. We'd want to refuse that extension if the extension is
> > found, but the version is not listed as being something compatible with
> > x.z.0, and while the ISA spec does say that the default assumption is
> > 2p0 for unversioned extensions in its current form, I struggle to
> > extrapolate that to extensions not currently part of the unpriv spec,
> > but rather defined on their own.
> >
> 
> That's a fair point. However, any new RVI ISA extension will only have v1.0
> as per my knowledge. Any new feature will have to be part of a
> different extension.
> At least that was the plan discussed last year.

That's more than last year at this point, and nothing has changed in the
documentation! Talk's cheap, ehh?

> https://github.com/riscv/riscv-isa-manual/issues/781#issuecomment-983222655
> 
> Are you aware of any discussion that changes this ?

It's called "trust issues". I am far less worried about the addition of
new features though than the removal of existing ones.
Part of me fears for fence.i-less systems for example, but there would
be other ways to bodge around the mess if it comes to pass.
If we are *sure* that no extensions will modify features additively or
subtractively, then this may not be needed at all & I can avoid having
to bend dt-validate to my will.
We have no guarantees for vendor extensions on that front either,
they're free to do what they like w.r.t. versioning, no?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230511/ab57a507/attachment.sig>