[RFC 2/6] dt-bindings: riscv: add riscv,isa-extension-* property and incompatible example

[Conor Dooley]

On Sat, May 13, 2023 at 07:50:22PM +0200, Krzysztof Kozlowski wrote:
> On 08/05/2023 20:16, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley at microchip.com>
> > 
> > This dt-binding is illustrative *only*, it doesn't yet do what I want it
> > to do in terms of enforcement etc. I am yet to figure out exactly how to
> > wrangle the binding such that the individual properties have more
> > generous versions than the generic pattern property.
> > This binding *will* generate errors, and needs rework before it can
> > seriously be considered.
> > Nevertheless, it should demonstrate how I intend such a property be
> > used.

> > +    oneOf:
> > +      - const: v1.0.0
> > +        description: the original incarnation
> > +      - const: v1.0.1
> > +        description: backwards compat was broken here
> > +
> > +patternProperties:
> > +  "^riscv,isa-extension-*":
> 
> Are all these -i/-m/-a extensions obvious/known to RISC-V folks? I have
> no clue what's this, so the question is: do they need some explanation
> in the bindings?

Yes, these should be well known. In the same way that "neon" should mean
something to someone doing arm64. Nevertheless, the plan is to drop the
string side of this entirely & actually document the meaning of -i/-m/-a
etc.

> > +    description:
> > +      Catch-all property for ISA extensions that do not need any special
> > +      handling, and of which all known versions are compatible with their
> > +      original revision.
> > +    $ref: "/schemas/types.yaml#/definitions/string"
> 
> Drop quotes.
> 
> > +    enum:
> > +      - v1.0.0
> 
> Your example should not validate here... you have there v2.0.0 and v1.0.1

As noted in the commit message, this is illustrative only & cannot work.
There doesn't appear to be a way to make the patternProperty fallback
more specific than the explicitly defined properties.
I wanted to get something out for initial thoughts before trying to do
further wrangling, lest it be a complete waste of time.
Consensus seems to be that versions are a thing of the past and that
property-presence based probing is a better idea. See the discussion
on the cover for that.
It does conveniently mean that all this complexity can be thrown in the
bin.

Cheers,
Conor.
-------------- 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/20230513/f67d64a6/attachment.sig>