Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp486959rdd; Tue, 9 Jan 2024 10:02:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IFpU8I3jEdIXrbDo8wVzkI/YI+/z52UMpgeyN4MQ9XyDJHnfR2OtVG4L3pzCaxVI1EzESYb X-Received: by 2002:a50:ab16:0:b0:557:367c:67df with SMTP id s22-20020a50ab16000000b00557367c67dfmr1711267edc.5.1704823330928; Tue, 09 Jan 2024 10:02:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704823330; cv=none; d=google.com; s=arc-20160816; b=BAdV//MLQdUc9Zf3NtW+FPb2US3+ahcymp433kJpjCYzT13+qy0+GUHwXYoB88u6gJ nSmX+Y3snFUj0wLrF8ZPwvDHae46055Zkc/z+UuizLQgE7XJts++gIQQ1C2K72g1ByM6 SjsPvO1493wlHBdD9r17zq8MDDGcPCtQXRHjkfaWybjb8/HPTu3j7KVZcMqZSo75X3Pe Sw7ZhaZP4h2zZ00zLpRn6KCBwD/7/AR7hUdhi7wD1g286jdIUdEeTRQnIoLssm3eiVIL b2lgNsZG1eC/a/c30R6PGZiG4fS0avEMdEs8LC66hR/9rJ7OcBmH+MqkKFAxVUvgk+fo MI1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=C3beLx3HiTc67VuKxfma3dg3VVEV03g23M8ZopXn2Ts=; fh=Ix1hW+sh82qEBaChGDylmz94mHG/Vp5iXAUG2j/0274=; b=u0mBlX9bBPwfL77lJxyz5FQ3bvjbx0TQFTZJwLtbA5CfvWV1qL1ve71u2MMJhAVDrV 8pkJx+lfjk+K8xWlhfM82K2C7pIp5/uWwjOHQDE8MX6B/9r4d8R4bpaMLshSFe2iWH2i s1Tde13CKXHlUdHlK5TXUOwJPkqha9U6Fkspn2KIaznOoCxm5SqcB8J6hUQJ2lqJNb6u +LvXwOrmiPnrWm0jGWOBKR62DZKEs+HucCbg+Jl/0MQ6JMmBLz9SK1UlVlHLroEVA268 qDxxLFIhh4tBlnwAx74dgH/v1LMSqGJaVLDGGveiJdbJ88pzDDWLAgJegVyoaAvnmmm3 LQTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sJiZ0TAr; spf=pass (google.com: domain of linux-kernel+bounces-21205-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id m20-20020a509994000000b00553a6299071si931664edb.690.2024.01.09.10.02.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 10:02:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21205-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sJiZ0TAr; spf=pass (google.com: domain of linux-kernel+bounces-21205-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 42B091F22527 for ; Tue, 9 Jan 2024 18:01:56 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 708A63BB53; Tue, 9 Jan 2024 18:00:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sJiZ0TAr" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6F5B33BB25; Tue, 9 Jan 2024 18:00:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 628B3C433F1; Tue, 9 Jan 2024 18:00:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704823254; bh=ymvzUtrJXnlHdMLNcKVm+KFBPspEJjs12uHChhr3maI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sJiZ0TArj6/22B0pPKyLwA0bzPVF3T2u3klppNGGEGHUO8M3BDFkwqrb2kwrfM5qM n8OPX5yutZE5G/UhksJ5cC45vCz64GkCX/M6AWwQxrax01A3STbsKYAKu1F1mPcGJ+ bR3uj/Vh3XkYPmHDi1H1UJ2dMSusvalAqMh97599hj9F185gIgppESZUFItPAS50Fg S09uA67w7fdcUfEWOniP5ND3dOejivKCVhjuFBECC0uzb1Msa3bIwRy7OT17b8Aum+ t6KsfYBwQKTV5BzlJ5PD1DukrbUrHZc/iioiSTLRbCMeo5N0GMwf/BNU6MCUWdiCNp Qkw3rr9mZt88Q== Date: Tue, 9 Jan 2024 18:00:41 +0000 From: Conor Dooley To: Yoshinori Sato Cc: linux-sh@vger.kernel.org, Damien Le Moal , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Geert Uytterhoeven , Michael Turquette , Stephen Boyd , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Thomas Gleixner , Lorenzo Pieralisi , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Bjorn Helgaas , Greg Kroah-Hartman , Jiri Slaby , Magnus Damm , Daniel Lezcano , Rich Felker , John Paul Adrian Glaubitz , Lee Jones , Helge Deller , Heiko Stuebner , Jernej Skrabec , Chris Morgan , Yang Xiwen , Sebastian Reichel , Linus Walleij , Randy Dunlap , Arnd Bergmann , Vlastimil Babka , Hyeonggon Yoo <42.hyeyoo@gmail.com>, David Rientjes , Baoquan He , Andrew Morton , Guenter Roeck , Stephen Rothwell , Azeem Shaikh , Javier Martinez Canillas , Max Filippov , Palmer Dabbelt , Bin Meng , Jonathan Corbet , Jacky Huang , Lukas Bulwahn , Biju Das , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Sam Ravnborg , Sergey Shtylyov , Michael Karcher , Laurent Pinchart , linux-ide@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-clk@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-pci@vger.kernel.org, linux-serial@vger.kernel.org, linux-fbdev@vger.kernel.org Subject: Re: [DO NOT MERGE v6 24/37] dt-binding: sh: cpus: Add SH CPUs json-schema Message-ID: <20240109-hankie-glacier-a55818f28b91@spud> References: <2e8be1e493f315c486b3113adf5d2164c3cd29e2.1704788539.git.ysato@users.sourceforge.jp> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xPLBpXcvOkLaXIuy" Content-Disposition: inline In-Reply-To: <2e8be1e493f315c486b3113adf5d2164c3cd29e2.1704788539.git.ysato@users.sourceforge.jp> --xPLBpXcvOkLaXIuy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yo, On Tue, Jan 09, 2024 at 05:23:21PM +0900, Yoshinori Sato wrote: > Renesas SH series and compatible ISA CPUs. >=20 > Signed-off-by: Yoshinori Sato > --- > .../devicetree/bindings/sh/cpus.yaml | 74 +++++++++++++++++++ > 1 file changed, 74 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sh/cpus.yaml >=20 > diff --git a/Documentation/devicetree/bindings/sh/cpus.yaml b/Documentati= on/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 > + > +description: |+ > + The device tree allows to describe the layout of CPUs in a system thro= ugh > + 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 = =66rom: > + > + 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 > + cpus { > + #address-cells =3D <1>; > + #size-cells =3D <0>; > + > + cpu: cpu@0 { > + compatible =3D "renesas,sh4", "renesas,sh2"; > + device_type =3D "cpu"; > + reg =3D <0>; > + clocks =3D <&cpg SH7750_CPG_ICK>; > + clock-names =3D "ick"; > + icache-size =3D <16384>; > + icache-line-size =3D <32>; > + dcache-size =3D <32768>; > + dcache-line-size =3D <32>; > + }; > + }; > +... > --=20 > 2.39.2 >=20 --xPLBpXcvOkLaXIuy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZZ2JyAAKCRB4tDGHoIJi 0hT2AP9R2UBDSiiyTAVtH1K3WE+zVT0M8gt7NsMcQVJTKbB22wD/TgGz2+9lyG+T 38cOZyNYa1mVFqzsmAghyWQdNloznwo= =N8JY -----END PGP SIGNATURE----- --xPLBpXcvOkLaXIuy--