On Tue, May 30, 2023 at 03:12:12PM +0100, Conor Dooley wrote:
> On Thu, May 18, 2023 at 10:42:34PM +0100, Conor Dooley wrote:
> > On Thu, May 18, 2023 at 02:30:53PM -0400, Sean Anderson wrote:
>
> > >
> > > Why not just have something like
> > >
> > > mycpu {
> > > ...
> > > riscv,isa {
> > > i;
> > > m;
> > > a;
> > > zicsr;
> > > ...
I prefer property names be globally unique. The tools are geared towards
that too. That's largely a symptom of having 0 type information in the
DT.
For example if you had an extension called 'reg', it would be a problem.
> > > };
> > > };
> >
> > Naming of the node aside (perhaps that could be riscv,isa-extensions)
> > there's not something hitting me immediately as to why that is a no-no.
> > If the size is a concern, this would certainly be more efficient & not
> > like the probing would be anything other than trivial more difficult
> > what I have in my proposal.
>
> Having started messing around with this, one of the main advantages, to
> me, of this approach is proper validation.
> cpus.yaml has additionalProperties: true in it, which would have had to
> be sorted out, or worked around, but creating a child-node with the
> properties in it allows setting additionalProperties: false.
That's an issue on my radar to fix. I started that for the Arm cpus.yaml
a while back. Sadly it involves adding all the misc properties vendors
added. It's not a lot, but still better to get in front of that for
Risc-V.
> > Rob's AFK at the moment, and I was hoping that he would take a look at
> > the idea, so I won't respin til he is back, but I'll give this a go in
> > the interim.
>
> Mechanically, the conversion of the patch isn't difficult, but I'll still
> wait for Rob to come back before sending a v2. But that v2 will more
> than likely implement your suggestion.
I haven't read the whole thread, but the initial proposal looks okay to
me.
Another way you could do this is a list of strings:
riscv,isa-ext = "i", "m", "zicsr";
I think we have a helper to test is a string in the list.
Rob
