All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.