From: Rob Herring <robh@kernel.org>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Conor Dooley <conor@kernel.org>,
Sean Anderson <sean.anderson@seco.com>,
Anup Patel <anup@brainfault.org>,
Andrew Jones <ajones@ventanamicro.com>,
palmer@dabbelt.com, Paul Walmsley <paul.walmsley@sifive.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Alistair Francis <alistair.francis@wdc.com>,
Anup Patel <apatel@ventanamicro.com>,
Atish Patra <atishp@atishpatra.org>,
Jessica Clarke <jrtc27@jrtc27.com>,
Rick Chen <rick@andestech.com>, Leo <ycliang@andestech.com>,
linux-riscv@lists.infradead.org, qemu-riscv@nongnu.org,
u-boot@lists.denx.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
Date: Thu, 8 Jun 2023 13:15:37 -0600 [thread overview]
Message-ID: <20230608191537.GA3233857-robh@kernel.org> (raw)
In-Reply-To: <20230530-duller-reset-a34ae111f207@wendy>
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Conor Dooley <conor@kernel.org>,
Sean Anderson <sean.anderson@seco.com>,
Anup Patel <anup@brainfault.org>,
Andrew Jones <ajones@ventanamicro.com>,
palmer@dabbelt.com, Paul Walmsley <paul.walmsley@sifive.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Alistair Francis <alistair.francis@wdc.com>,
Anup Patel <apatel@ventanamicro.com>,
Atish Patra <atishp@atishpatra.org>,
Jessica Clarke <jrtc27@jrtc27.com>,
Rick Chen <rick@andestech.com>, Leo <ycliang@andestech.com>,
linux-riscv@lists.infradead.org, qemu-riscv@nongnu.org,
u-boot@lists.denx.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
Date: Thu, 8 Jun 2023 13:15:37 -0600 [thread overview]
Message-ID: <20230608191537.GA3233857-robh@kernel.org> (raw)
In-Reply-To: <20230530-duller-reset-a34ae111f207@wendy>
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
next prev parent reply other threads:[~2023-06-08 19:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 8:58 [PATCH v1] dt-bindings: riscv: deprecate riscv,isa Conor Dooley
2023-05-18 8:58 ` Conor Dooley
2023-05-18 10:31 ` Andrew Jones
2023-05-18 10:31 ` Andrew Jones
2023-05-18 11:15 ` Conor Dooley
2023-05-18 11:15 ` Conor Dooley
2023-05-18 11:25 ` Conor Dooley
2023-05-18 11:25 ` Conor Dooley
2023-05-18 13:43 ` Anup Patel
2023-05-18 13:43 ` Anup Patel
2023-05-18 14:06 ` Conor Dooley
2023-05-18 14:06 ` Conor Dooley
2023-05-18 14:41 ` Palmer Dabbelt
2023-05-18 14:41 ` Palmer Dabbelt
2023-05-18 17:06 ` Conor Dooley
2023-05-18 17:06 ` Conor Dooley
2023-05-18 18:30 ` Sean Anderson
2023-05-18 18:30 ` Sean Anderson
2023-05-18 21:42 ` Conor Dooley
2023-05-18 21:42 ` Conor Dooley
2023-05-30 14:12 ` Conor Dooley
2023-05-30 14:12 ` Conor Dooley
2023-06-08 19:15 ` Rob Herring [this message]
2023-06-08 19:15 ` Rob Herring
2023-06-08 19:30 ` Conor Dooley
2023-06-08 19:30 ` Conor Dooley
2023-06-12 21:23 ` Conor Dooley
2023-06-12 21:23 ` Conor Dooley
2023-06-13 13:28 ` Rob Herring
2023-06-13 13:28 ` Rob Herring
2023-06-13 14:11 ` Conor Dooley
2023-06-13 14:11 ` Conor Dooley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230608191537.GA3233857-robh@kernel.org \
--to=robh@kernel.org \
--cc=ajones@ventanamicro.com \
--cc=alistair.francis@wdc.com \
--cc=anup@brainfault.org \
--cc=apatel@ventanamicro.com \
--cc=atishp@atishpatra.org \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jrtc27@jrtc27.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=qemu-riscv@nongnu.org \
--cc=rick@andestech.com \
--cc=sean.anderson@seco.com \
--cc=u-boot@lists.denx.de \
--cc=ycliang@andestech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.