[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240109-hankie-glacier-a55818f28b91@spud>
Date: Tue, 9 Jan 2024 18:00:41 +0000
From: Conor Dooley <conor@...nel.org>
To: Yoshinori Sato <ysato@...rs.sourceforge.jp>
Cc: linux-sh@...r.kernel.org, Damien Le Moal <dlemoal@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
Thomas Gleixner <tglx@...utronix.de>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kw@...ux.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Magnus Damm <magnus.damm@...il.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Rich Felker <dalias@...c.org>,
John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
Lee Jones <lee@...nel.org>, Helge Deller <deller@....de>,
Heiko Stuebner <heiko@...ech.de>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Chris Morgan <macromorgan@...mail.com>,
Yang Xiwen <forbidden405@...mail.com>,
Sebastian Reichel <sre@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Randy Dunlap <rdunlap@...radead.org>, Arnd Bergmann <arnd@...db.de>,
Vlastimil Babka <vbabka@...e.cz>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
David Rientjes <rientjes@...gle.com>, Baoquan He <bhe@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Guenter Roeck <linux@...ck-us.net>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Azeem Shaikh <azeemshaikh38@...il.com>,
Javier Martinez Canillas <javierm@...hat.com>,
Max Filippov <jcmvbkbc@...il.com>,
Palmer Dabbelt <palmer@...osinc.com>, Bin Meng <bmeng@...ylab.org>,
Jonathan Corbet <corbet@....net>,
Jacky Huang <ychuang3@...oton.com>,
Lukas Bulwahn <lukas.bulwahn@...il.com>,
Biju Das <biju.das.jz@...renesas.com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
Sam Ravnborg <sam@...nborg.org>,
Sergey Shtylyov <s.shtylyov@....ru>,
Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
linux-ide@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
linux-clk@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-pci@...r.kernel.org, linux-serial@...r.kernel.org,
linux-fbdev@...r.kernel.org
Subject: Re: [DO NOT MERGE v6 24/37] dt-binding: sh: cpus: Add SH CPUs
json-schema
Yo,
On Tue, Jan 09, 2024 at 05:23:21PM +0900, Yoshinori Sato wrote:
> Renesas SH series and compatible ISA CPUs.
>
> Signed-off-by: Yoshinori Sato <ysato@...rs.sourceforge.jp>
> ---
> .../devicetree/bindings/sh/cpus.yaml | 74 +++++++++++++++++++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sh/cpus.yaml
>
> diff --git a/Documentation/devicetree/bindings/sh/cpus.yaml b/Documentation/devicetree/bindings/sh/cpus.yaml
> new file mode 100644
> index 000000000000..c04f897d2c2a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sh/cpus.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sh/cpus.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SuperH CPUs
> +
> +maintainers:
> + - Yoshinori Sato <ysato@...rs.sourceforge.jp>
> +
> +description: |+
> + The device tree allows to describe the layout of CPUs in a system through
> + the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> + defining properties for every cpu.
> +
> + Bindings for CPU nodes follow the Devicetree Specification, available from:
> +
> + https://www.devicetree.org/specifications/
You likely copied this description from the arm binding (or from
dt-schema), but I don't think this is anything other than a statement of
the obvious. If there is a description here it should (IMO) talk about
the superh cpus.
> +
> +properties:
> + compatible:
> + anyOf:
> + - items:
> + - enum:
> + - renesas,sh2a
> + - renesas,sh3
> + - renesas,sh4
> + - renesas,sh4a
> + - jcore,j2
> + - const: renesas,sh2
> + - const: renesas,sh2
> +
> + clock-frequency:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: CPU core clock frequency.
What is the point of this? You have a clocks property, can't you obtain
the clock frequency by looking up the provider of that clock?
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names: true
Why do you need clock-names if you only have one clock?
> +
> + reg:
> + maxItems: 1
> +
> + device_type: true
> +
> +required:
> + - compatible
> + - reg
> + - device_type
> +
> +additionalProperties: true
This should be unevaluatedProperties: false
Properties like the icache-size are documented in cpu.yaml and
you can add an reference to that to permit them. The riscv cpus binding
does this if you need to see how that works.
Cheers,
Conor.
> +examples:
> + - |
> + #include <dt-bindings/clock/sh7750-cpg.h>
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu: cpu@0 {
> + compatible = "renesas,sh4", "renesas,sh2";
> + device_type = "cpu";
> + reg = <0>;
> + clocks = <&cpg SH7750_CPG_ICK>;
> + clock-names = "ick";
> + icache-size = <16384>;
> + icache-line-size = <32>;
> + dcache-size = <32768>;
> + dcache-line-size = <32>;
> + };
> + };
> +...
> --
> 2.39.2
>
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists