| Message ID | 20181005165848.3474-1-robh@kernel.org |
|---|---|
| Headers | show |
| Series | Devicetree schema | expand |
Hello, On 05/10/2018 11:58:31-0500, Rob Herring wrote: > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > new file mode 100644 > index 000000000000..f788315b94fa > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > @@ -0,0 +1,132 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/atmel-at91.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Atmel AT91 device tree bindings. > + > +maintainers: > + - Alexandre Belloni <alexandre.belloni@free-electrons.com> > + - Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Jean-Christophe has not been active for years, I'd mention Ludovic instead. > +description: | > + Boards with a SoC of the Atmel AT91 or SMART family shall have the following > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - const: atmel,at91rm9200 > + - items: > + - enum: > + - olimex,sam9-l9260 > + - enum: > + - atmel,at91sam9260 > + - atmel,at91sam9261 > + - atmel,at91sam9263 > + - atmel,at91sam9g20 > + - atmel,at91sam9g45 > + - atmel,at91sam9n12 > + - atmel,at91sam9rl > + - atmel,at91sam9xe > + - const: atmel,at91sam9 > + > + - items: > + - enum: > + - atmel,at91sam9g15 > + - atmel,at91sam9g25 > + - atmel,at91sam9g35 > + - atmel,at91sam9x25 > + - atmel,at91sam9x35 > + - const: atmel,at91sam9x5 > + - const: atmel,at91sam9 > + > + - items: > + - const: atmel,sama5d27 > + - const: atmel,sama5d2 > + - const: atmel,sama5 > + > + - description: Nattis v2 board with Natte v2 power board > + items: > + - const: axentia,nattis-2 > + - const: axentia,natte-2 > + - const: axentia,linea Shouldn't we have the board specific compatibles in a separate file to avoid mixing everything with the SoC compatibles? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Fri, Oct 5, 2018 at 1:07 PM Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > Hello, > > On 05/10/2018 11:58:31-0500, Rob Herring wrote: > > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > > new file mode 100644 > > index 000000000000..f788315b94fa > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > > @@ -0,0 +1,132 @@ > > +# SPDX-License-Identifier: None > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/bindings/arm/atmel-at91.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Atmel AT91 device tree bindings. > > + > > +maintainers: > > + - Alexandre Belloni <alexandre.belloni@free-electrons.com> > > + - Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> > > Jean-Christophe has not been active for years, I'd mention Ludovic > instead. Will update. I generated these out of git log. I didn't use get_maintainers.pl because it seems lots of files don't have maintainers listed (other than Mark and me) and I didn't want to be it. > > > +description: | > > + Boards with a SoC of the Atmel AT91 or SMART family shall have the following > > + > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - items: > > + - const: atmel,at91rm9200 > > + - items: > > + - enum: > > + - olimex,sam9-l9260 > > + - enum: > > + - atmel,at91sam9260 > > + - atmel,at91sam9261 > > + - atmel,at91sam9263 > > + - atmel,at91sam9g20 > > + - atmel,at91sam9g45 > > + - atmel,at91sam9n12 > > + - atmel,at91sam9rl > > + - atmel,at91sam9xe > > + - const: atmel,at91sam9 > > + > > + - items: > > + - enum: > > + - atmel,at91sam9g15 > > + - atmel,at91sam9g25 > > + - atmel,at91sam9g35 > > + - atmel,at91sam9x25 > > + - atmel,at91sam9x35 > > + - const: atmel,at91sam9x5 > > + - const: atmel,at91sam9 > > + > > + - items: > > + - const: atmel,sama5d27 > > + - const: atmel,sama5d2 > > + - const: atmel,sama5 > > + > > + - description: Nattis v2 board with Natte v2 power board > > + items: > > + - const: axentia,nattis-2 > > + - const: axentia,natte-2 > > + - const: axentia,linea > > Shouldn't we have the board specific compatibles in a separate file to > avoid mixing everything with the SoC compatibles? You can't validate it that way. I have to say "must be compatible A, B, C and in that order" and you can't if A, B, and C are in different files. We could do board vendor files, but then we have to duplicate the SoC compatibles. I don't think there's any board vendor with enough boards to justify that. The only place I've found that the compatible lists get kind of messy is when platforms have a variable number of compatible strings. We generally have not split things this way for most platforms except i.MX which this series changes. Looks like I forgot to remove the axentia.txt for Atmel. Rob
Hi Rob On Fri, 2018-10-05 at 11:58 -0500, Rob Herring wrote: > Convert Tegra SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Thierry Reding <thierry.reding@gmail.com> > Cc: Jonathan Hunter <jonathanh@nvidia.com> > Cc: devicetree@vger.kernel.org > Cc: linux-tegra@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/tegra.txt | 60 ------------- > .../devicetree/bindings/arm/tegra.yaml | 88 > +++++++++++++++++++ > 2 files changed, 88 insertions(+), 60 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt > create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml > > diff --git a/Documentation/devicetree/bindings/arm/tegra.txt > b/Documentation/devicetree/bindings/arm/tegra.txt > deleted file mode 100644 > index 32f62bb7006d..000000000000 > --- a/Documentation/devicetree/bindings/arm/tegra.txt > +++ /dev/null > @@ -1,60 +0,0 @@ > -NVIDIA Tegra device tree bindings > -------------------------------------------- > - > -SoCs > -------------------------------------------- > - > -Each device tree must specify which Tegra SoC it uses, using one of > the > -following compatible values: > - > - nvidia,tegra20 > - nvidia,tegra30 > - nvidia,tegra114 > - nvidia,tegra124 > - nvidia,tegra132 > - nvidia,tegra210 > - nvidia,tegra186 > - nvidia,tegra194 > - > -Boards > -------------------------------------------- > - > -Each device tree must specify which one or more of the following > -board-specific compatible values: > - > - ad,medcom-wide > - ad,plutux > - ad,tamonten > - ad,tec > - compal,paz00 > - compulab,trimslice > - nvidia,beaver > - nvidia,cardhu > - nvidia,cardhu-a02 > - nvidia,cardhu-a04 > - nvidia,dalmore > - nvidia,harmony > - nvidia,jetson-tk1 > - nvidia,norrin > - nvidia,p2371-0000 > - nvidia,p2371-2180 > - nvidia,p2571 > - nvidia,p2771-0000 > - nvidia,p2972-0000 > - nvidia,roth > - nvidia,seaboard > - nvidia,tn7 > - nvidia,ventana > - toradex,apalis_t30 > - toradex,apalis_t30-eval > - toradex,apalis-tk1 > - toradex,apalis-tk1-eval > - toradex,colibri_t20-512 > - toradex,colibri_t30 > - toradex,colibri_t30-eval-v3 > - toradex,iris Are you aware that -next already features a few updating commits thereof from around the beginning of September one of which even bears your reviewed-by. > - > -Trusted Foundations > -------------------------------------------- > -Tegra supports the Trusted Foundation secure monitor. See the > -"tlm,trusted-foundations" binding's documentation for more details. > diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml > b/Documentation/devicetree/bindings/arm/tegra.yaml > new file mode 100644 > index 000000000000..9cebcfaaad1e > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml > @@ -0,0 +1,88 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/tegra.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: NVIDIA Tegra device tree bindings > + > +maintainers: > + - Marcel Ziswiler <marcel.ziswiler@toradex.com> Wow, seems I got promoted to maintainer now. I guess that may make sense at least for the Toradex based boards. > + - Peter De Schrijver <pdeschrijver@nvidia.com> > + > +properties: > + compatible: > + oneOf: > + - items: > + - enum: > + - compal,paz00 > + - compulab,trimslice > + - nvidia,harmony > + - nvidia,seaboard > + - nvidia,ventana > + - const: nvidia,tegra20 > + - items: > + - enum: > + - ad,medcom-wide > + - ad,plutux > + - ad,tec > + - const: ad,tamonten > + - const: nvidia,tegra20 > + - items: > + - const: toradex,iris > + - const: toradex,colibri_t20-512 > + - const: nvidia,tegra20 > + - items: > + - enum: > + - nvidia,beaver > + - const: nvidia,tegra30 > + - items: > + - enum: > + - nvidia,cardhu-a02 > + - nvidia,cardhu-a04 > + - const: nvidia,cardhu > + - const: nvidia,tegra30 > + - items: > + - enum: > + - toradex,apalis_t30-eval > + - const: toradex,apalis_t30 > + - const: nvidia,tegra30 > + - items: > + - enum: > + - toradex,colibri_t30-eval-v3 > + - const: toradex,colibri_t30 > + - const: nvidia,tegra30 > + - items: > + - enum: > + - nvidia,dalmore > + - nvidia,roth > + - nvidia,tn7 > + - const: nvidia,tegra114 > + - items: > + - enum: > + - nvidia,jetson-tk1 > + - nvidia,venice2 > + - const: nvidia,tegra124 > + - items: > + - const: toradex,apalis-tk1-eval > + - const: toradex,apalis-tk1 > + - const: nvidia,tegra124 > + - items: > + - enum: > + - nvidia,norrin > + - const: nvidia,tegra132 > + - const: nvidia,tegra124 > + - items: > + - enum: > + - nvidia,p2371-0000 > + - nvidia,p2371-2180 > + - nvidia,p2571 > + - const: nvidia,tegra210 > + - items: > + - enum: > + - nvidia,p2771-0000 > + - const: nvidia,tegra186 > + - items: > + - enum: > + - nvidia,p2972-0000 > + - const: nvidia,tegra194 Other than that I'm all in to move towards more structured bindings documentation. Cheers Marcel
On Fri, Oct 5, 2018 at 5:20 PM Marcel Ziswiler <marcel.ziswiler@toradex.com> wrote: > > Hi Rob > > On Fri, 2018-10-05 at 11:58 -0500, Rob Herring wrote: > > Convert Tegra SoC bindings to DT schema format using json-schema. > > [...] > Are you aware that -next already features a few updating commits > thereof from around the beginning of September one of which even bears > your reviewed-by. I'm not targeting 4.20, but rather early in the 4.21 cycle. So I'll be rebasing on rc1 and will update with any changes. I've been doing that a couple of cycles already. Rob
Am 05.10.18 um 18:58 schrieb Rob Herring: > Convert Realtek SoC bindings to DT schema format using json-schema. YAML (2x) > > Cc: "Andreas Färber" <afaerber@suse.de> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-arm-kernel@lists.infradead.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/realtek.txt | 22 ---------------- > .../devicetree/bindings/arm/realtek.yaml | 25 +++++++++++++++++++ > 2 files changed, 25 insertions(+), 22 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/realtek.txt > create mode 100644 Documentation/devicetree/bindings/arm/realtek.yaml > > diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt > deleted file mode 100644 > index 95839e19ae92..000000000000 > --- a/Documentation/devicetree/bindings/arm/realtek.txt > +++ /dev/null > @@ -1,22 +0,0 @@ > -Realtek platforms device tree bindings > --------------------------------------- > - > - > -RTD1295 SoC > -=========== > - > -Required root node properties: > - > - - compatible : must contain "realtek,rtd1295" > - > - > -Root node property compatible must contain, depending on board: > - > - - MeLE V9: "mele,v9" > - - ProBox2 AVA: "probox2,ava" > - - Zidoo X9S: "zidoo,x9s" > - > - > -Example: > - > - compatible = "zidoo,x9s", "realtek,rtd1295"; > diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml > new file mode 100644 > index 000000000000..9e3bb3249c77 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/realtek.yaml > @@ -0,0 +1,25 @@ > +# SPDX-License-Identifier: None What is the expected license for such bindings? You did not add such a line for actions.yaml. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/realtek.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Realtek platforms device tree bindings > + > +maintainers: > + - Andreas Färber <afaerber@suse.de> > + > +description: |+ "|+"? > + RTD1295 SoC > + > +properties: > + $nodename: > + const: '/' > + compatible: > + items: > + - enum: > + - mele,v9 > + - probox2,ava > + - zidoo,x9s > + - const: realtek,rtd1295 > +... That does not look like a full "PATCH" yet? It also confuses me whether or when leading dashes are necessary - for Actions Semi "items" had one. I have preparations on my GitHub staging tree for three more SoCs, so we should prepare the structure to ease adding SoCs and avoid re-indenting patches - adding SoCs was much easier in the original flat text format. Please also consider for other vendors. Same comment as for Actions: We're losing a human description of the enum values. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
On Sat, Oct 6, 2018 at 5:54 AM Andreas Färber <afaerber@suse.de> wrote: > > Am 05.10.18 um 18:58 schrieb Rob Herring: > > Convert Realtek SoC bindings to DT schema format using json-schema. > > YAML (2x) ? > > Cc: "Andreas Färber" <afaerber@suse.de> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/arm/realtek.txt | 22 ---------------- > > .../devicetree/bindings/arm/realtek.yaml | 25 +++++++++++++++++++ > > 2 files changed, 25 insertions(+), 22 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/realtek.txt > > create mode 100644 Documentation/devicetree/bindings/arm/realtek.yaml > > > > diff --git a/Documentation/devicetree/bindings/arm/realtek.txt b/Documentation/devicetree/bindings/arm/realtek.txt > > deleted file mode 100644 > > index 95839e19ae92..000000000000 > > --- a/Documentation/devicetree/bindings/arm/realtek.txt > > +++ /dev/null > > @@ -1,22 +0,0 @@ > > -Realtek platforms device tree bindings > > --------------------------------------- > > - > > - > > -RTD1295 SoC > > -=========== > > - > > -Required root node properties: > > - > > - - compatible : must contain "realtek,rtd1295" > > - > > - > > -Root node property compatible must contain, depending on board: > > - > > - - MeLE V9: "mele,v9" > > - - ProBox2 AVA: "probox2,ava" > > - - Zidoo X9S: "zidoo,x9s" > > - > > - > > -Example: > > - > > - compatible = "zidoo,x9s", "realtek,rtd1295"; > > diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml b/Documentation/devicetree/bindings/arm/realtek.yaml > > new file mode 100644 > > index 000000000000..9e3bb3249c77 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/realtek.yaml > > @@ -0,0 +1,25 @@ > > +# SPDX-License-Identifier: None > > What is the expected license for such bindings? Good question. I'd meant to figure something out for this placeholder. The default would be GPL-2 inheriting from the old doc. My preference would be to dual license these with BSD as they're not just kernel files, but I don't really want to track down copyright holders (also not explicitly declared) to do that. > You did not add such a line for actions.yaml. > > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/bindings/arm/realtek.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Realtek platforms device tree bindings > > + > > +maintainers: > > + - Andreas Färber <afaerber@suse.de> > > + > > +description: |+ > > "|+"? The '|' means a literal block. The '+' is a block chomping indicator: http://yaml.org/spec/1.2/spec.html#id2794534 This was all converted using my doc2yaml script and ruamel.yaml decided it needed the '+'. I'm not sure exactly why. It may be based on how many trailing newlines the text had. > > + RTD1295 SoC In this case, this isn't really useful and we should just remove description unless you want to add something. > > + > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + items: > > + - enum: > > + - mele,v9 > > + - probox2,ava > > + - zidoo,x9s > > + - const: realtek,rtd1295 > > +... > > That does not look like a full "PATCH" yet? It also confuses me whether > or when leading dashes are necessary - for Actions Semi "items" had one. '...' is the end of YAML document marker. '-' means a list item (a YAML/JSON list, not to be confused with 'items' the json-schema keyword). Actions uses 'oneOf' (which is a list of schemas) because there are multiple SoCs. And also 'items' itself can be a list or dict, but we restrict it to lists for the DT meta-schema. > I have preparations on my GitHub staging tree for three more SoCs, so we > should prepare the structure to ease adding SoCs and avoid re-indenting > patches - adding SoCs was much easier in the original flat text format. > Please also consider for other vendors. Good point. One option is always use 'oneOf' even if just 1 item. The problem is that the use of oneOf/allOf/anyOf makes the error reporting pretty vague. Another option is to make each SoC a separate schema which could be either separate docs or multiple yaml docs within a file. The downside is just repeating all the top-level properties. > > Same comment as for Actions: We're losing a human description of the > enum values. I kept those as comments when there was meaningful information. I did not feel that "MeLE V9" as a description of "mele,v9" added any value. If you want to add 'model' schema that would be better than having just comments, but I'm not going to find all the values of model which aren't documented. Rob
On Fri, Oct 05, 2018 at 11:58:16AM -0500, Rob Herring wrote: > In preparation to convert board-level bindings to json-schema, move > various misc SoC bindings out to their own file. > > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Shawn Guo <shawnguo@kernel.org>
On Fri, Oct 05, 2018 at 11:58:18AM -0500, Rob Herring wrote: > In preparation to convert board-level bindings to json-schema, move > various misc SoC bindings out to their own file. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Jun Nie <jun.nie@linaro.org> > Cc: Baoyou Xie <baoyou.xie@linaro.org> > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/zte-sysctrl.txt | 30 +++++++++++++++++++ zte,sysctrl.txt to be consistent with other files like fsl,layerscape-dcfg.txt? I'm fine with either way, but just want to see more consistent naming convention? Other than that, Acked-by: Shawn Guo <shawnguo@kernel.org>
On Fri, Oct 05, 2018 at 11:58:34AM -0500, Rob Herring wrote: > Convert Freescale SoC bindings to DT schema format using json-schema. > > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/armadeus.txt | 6 - > Documentation/devicetree/bindings/arm/bhf.txt | 6 - > .../bindings/arm/compulab-boards.txt | 25 --- > Documentation/devicetree/bindings/arm/fsl.txt | 185 ------------------ > .../devicetree/bindings/arm/fsl.yaml | 166 ++++++++++++++++ > .../devicetree/bindings/arm/i2se.txt | 22 --- > .../devicetree/bindings/arm/olimex.txt | 10 - > .../devicetree/bindings/arm/technologic.txt | 23 --- > 8 files changed, 166 insertions(+), 277 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/armadeus.txt > delete mode 100644 Documentation/devicetree/bindings/arm/bhf.txt > delete mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt > delete mode 100644 Documentation/devicetree/bindings/arm/fsl.txt > create mode 100644 Documentation/devicetree/bindings/arm/fsl.yaml > delete mode 100644 Documentation/devicetree/bindings/arm/i2se.txt > delete mode 100644 Documentation/devicetree/bindings/arm/olimex.txt > delete mode 100644 Documentation/devicetree/bindings/arm/technologic.txt > > diff --git a/Documentation/devicetree/bindings/arm/armadeus.txt b/Documentation/devicetree/bindings/arm/armadeus.txt > deleted file mode 100644 > index 9821283ff516..000000000000 > --- a/Documentation/devicetree/bindings/arm/armadeus.txt > +++ /dev/null > @@ -1,6 +0,0 @@ > -Armadeus i.MX Platforms Device Tree Bindings > ------------------------------------------------ > - > -APF51: i.MX51 based module. > -Required root node properties: > - - compatible = "armadeus,imx51-apf51", "fsl,imx51"; > diff --git a/Documentation/devicetree/bindings/arm/bhf.txt b/Documentation/devicetree/bindings/arm/bhf.txt > deleted file mode 100644 > index 886b503caf9c..000000000000 > --- a/Documentation/devicetree/bindings/arm/bhf.txt > +++ /dev/null > @@ -1,6 +0,0 @@ > -Beckhoff Automation Platforms Device Tree Bindings > --------------------------------------------------- > - > -CX9020 Embedded PC > -Required root node properties: > - - compatible = "bhf,cx9020", "fsl,imx53"; > diff --git a/Documentation/devicetree/bindings/arm/compulab-boards.txt b/Documentation/devicetree/bindings/arm/compulab-boards.txt > deleted file mode 100644 > index 42a10285af9c..000000000000 > --- a/Documentation/devicetree/bindings/arm/compulab-boards.txt > +++ /dev/null > @@ -1,25 +0,0 @@ > -CompuLab SB-SOM is a multi-module baseboard capable of carrying: > - - CM-T43 > - - CM-T54 > - - CM-QS600 > - - CL-SOM-AM57x > - - CL-SOM-iMX7 > -modules with minor modifications to the SB-SOM assembly. > - > -Required root node properties: > - - compatible = should be "compulab,sb-som" > - > -Compulab CL-SOM-iMX7 is a miniature System-on-Module (SoM) based on > -Freescale i.MX7 ARM Cortex-A7 System-on-Chip. > - > -Required root node properties: > - - compatible = "compulab,cl-som-imx7", "fsl,imx7d"; > - > -Compulab SBC-iMX7 is a single board computer based on the > -Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with > -the CL-SOM-iMX7 System-on-Module providing most of the functions, > -and SB-SOM-iMX7 carrier board providing additional peripheral > -functions and connectors. > - > -Required root node properties: > - - compatible = "compulab,sbc-imx7", "compulab,cl-som-imx7", "fsl,imx7d"; > diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt > deleted file mode 100644 > index 1e775aaa5c5b..000000000000 > --- a/Documentation/devicetree/bindings/arm/fsl.txt > +++ /dev/null > @@ -1,185 +0,0 @@ > -Freescale i.MX Platforms Device Tree Bindings > ------------------------------------------------ > - > -i.MX23 Evaluation Kit > -Required root node properties: > - - compatible = "fsl,imx23-evk", "fsl,imx23"; > - > -i.MX25 Product Development Kit > -Required root node properties: > - - compatible = "fsl,imx25-pdk", "fsl,imx25"; > - > -i.MX27 Product Development Kit > -Required root node properties: > - - compatible = "fsl,imx27-pdk", "fsl,imx27"; > - > -i.MX28 Evaluation Kit > -Required root node properties: > - - compatible = "fsl,imx28-evk", "fsl,imx28"; > - > -i.MX51 Babbage Board > -Required root node properties: > - - compatible = "fsl,imx51-babbage", "fsl,imx51"; > - > -i.MX53 Automotive Reference Design Board > -Required root node properties: > - - compatible = "fsl,imx53-ard", "fsl,imx53"; > - > -i.MX53 Evaluation Kit > -Required root node properties: > - - compatible = "fsl,imx53-evk", "fsl,imx53"; > - > -i.MX53 Quick Start Board > -Required root node properties: > - - compatible = "fsl,imx53-qsb", "fsl,imx53"; > - > -i.MX53 Smart Mobile Reference Design Board > -Required root node properties: > - - compatible = "fsl,imx53-smd", "fsl,imx53"; > - > -i.MX6 Quad Armadillo2 Board > -Required root node properties: > - - compatible = "fsl,imx6q-arm2", "fsl,imx6q"; > - > -i.MX6 Quad SABRE Lite Board > -Required root node properties: > - - compatible = "fsl,imx6q-sabrelite", "fsl,imx6q"; > - > -i.MX6 Quad SABRE Smart Device Board > -Required root node properties: > - - compatible = "fsl,imx6q-sabresd", "fsl,imx6q"; > - > -i.MX6 Quad SABRE Automotive Board > -Required root node properties: > - - compatible = "fsl,imx6q-sabreauto", "fsl,imx6q"; > - > -i.MX6SLL EVK board > -Required root node properties: > - - compatible = "fsl,imx6sll-evk", "fsl,imx6sll"; > - > -Generic i.MX boards > -------------------- > - > -No iomux setup is done for these boards, so this must have been configured > -by the bootloader for boards to work with the generic bindings. > - > -i.MX27 generic board > -Required root node properties: > - - compatible = "fsl,imx27"; > - > -i.MX51 generic board > -Required root node properties: > - - compatible = "fsl,imx51"; > - > -i.MX53 generic board > -Required root node properties: > - - compatible = "fsl,imx53"; > - > -i.MX6q generic board > -Required root node properties: > - - compatible = "fsl,imx6q"; > - > -Freescale Vybrid Platform Device Tree Bindings > ----------------------------------------------- > - > -For the Vybrid SoC familiy all variants with DDR controller are supported, > -which is the VF5xx and VF6xx series. Out of historical reasons, in most > -places the kernel uses vf610 to refer to the whole familiy. > -The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4 > -core support. > - > -Required root node compatible property (one of them): > - - compatible = "fsl,vf500"; > - - compatible = "fsl,vf510"; > - - compatible = "fsl,vf600"; > - - compatible = "fsl,vf610"; > - - compatible = "fsl,vf610m4"; > - > -Freescale LS1021A Platform Device Tree Bindings > ------------------------------------------------- > - > -Required root node compatible properties: > - - compatible = "fsl,ls1021a"; > - > -Freescale ARMv8 based Layerscape SoC family Device Tree Bindings > ----------------------------------------------------------------- > - > -LS1012A SoC > -Required root node properties: > - - compatible = "fsl,ls1012a"; > - > -LS1012A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1012a-rdb", "fsl,ls1012a"; > - > -LS1012A ARMv8 based FRDM Board > -Required root node properties: > - - compatible = "fsl,ls1012a-frdm", "fsl,ls1012a"; > - > -LS1012A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1012a-qds", "fsl,ls1012a"; > - > -LS1043A SoC > -Required root node properties: > - - compatible = "fsl,ls1043a"; > - > -LS1043A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1043a-rdb", "fsl,ls1043a"; > - > -LS1043A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1043a-qds", "fsl,ls1043a"; > - > -LS1046A SoC > -Required root node properties: > - - compatible = "fsl,ls1046a"; > - > -LS1046A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1046a-qds", "fsl,ls1046a"; > - > -LS1046A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1046a-rdb", "fsl,ls1046a"; > - > -LS1088A SoC > -Required root node properties: > - - compatible = "fsl,ls1088a"; > - > -LS1088A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls1088a-qds", "fsl,ls1088a"; > - > -LS1088A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls1088a-rdb", "fsl,ls1088a"; > - > -LS2080A SoC > -Required root node properties: > - - compatible = "fsl,ls2080a"; > - > -LS2080A ARMv8 based Simulator model > -Required root node properties: > - - compatible = "fsl,ls2080a-simu", "fsl,ls2080a"; > - > -LS2080A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls2080a-qds", "fsl,ls2080a"; > - > -LS2080A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls2080a-rdb", "fsl,ls2080a"; > - > -LS2088A SoC > -Required root node properties: > - - compatible = "fsl,ls2088a"; > - > -LS2088A ARMv8 based QDS Board > -Required root node properties: > - - compatible = "fsl,ls2088a-qds", "fsl,ls2088a"; > - > -LS2088A ARMv8 based RDB Board > -Required root node properties: > - - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a"; > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml > new file mode 100644 > index 000000000000..5241fa92e3d1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/fsl.yaml > @@ -0,0 +1,166 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/fsl.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Freescale i.MX Platforms Device Tree Bindings > + > +maintainers: > + - Shawn Guo <shawn.guo@freescale.com> The email address has been unavailable for long time. Please use Shawn Guo <shawnguo@kernel.org>. > + - Shaohui Xie <Shaohui.Xie@nxp.com> Li Yang <leoyang.li@nxp.com> is the co-maintainer for Layerscape. > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - description: i.MX23 based Boards > + items: > + - enum: > + - fsl,imx23-evk > + - olimex,imx23-olinuxino > + - const: fsl,imx23 > + > + - description: i.MX25 Product Development Kit > + items: > + - enum: > + - fsl,imx25-pdk > + - const: fsl,imx25 > + > + - description: i.MX27 Product Development Kit > + items: > + - enum: > + - fsl,imx27-pdk > + - const: fsl,imx27 > + > + - description: i.MX28 based Boards > + items: > + - enum: > + - fsl,imx28-evk > + - i2se,duckbill > + - i2se,duckbill-2 > + - technologic,imx28-ts4600 > + - const: fsl,imx28 > + - items: The schema is new to me. This line looks unusual to me, so you may want to double check. > + - enum: > + - i2se,duckbill-2-485 > + - i2se,duckbill-2-enocean > + - i2se,duckbill-2-spi > + - const: i2se,duckbill-2 > + - const: fsl,imx28 > + > + - description: i.MX51 Babbage Board i.MX51 based Boards > + items: > + - enum: > + - armadeus,imx51-apf51 > + - fsl,imx51-babbage > + - technologic,imx51-ts4800 > + - const: fsl,imx51 > + > + - description: i.MX53 Boards i.MX53 based Boards Shawn > + items: > + - enum: > + - bhf,cx9020 > + - fsl,imx53-ard > + - fsl,imx53-evk > + - fsl,imx53-qsb > + - fsl,imx53-smd > + - const: fsl,imx53 > + > + - description: i.MX6Q based Boards > + items: > + - enum: > + - fsl,imx6q-arm2 > + - fsl,imx6q-sabrelite > + - fsl,imx6q-sabresd > + - fsl,imx6q-sabreauto > + - technologic,imx6q-ts4900 > + - technologic,imx6q-ts7970 > + - const: fsl,imx6q > + > + - description: i.MX6DL based Boards > + items: > + - enum: > + - technologic,imx6dl-ts4900 > + - technologic,imx6dl-ts7970 > + - const: fsl,imx6dl > + > + - description: i.MX6SLL based Boards > + items: > + - enum: > + - fsl,imx6sll-evk > + - const: fsl,imx6sll > + > + - description: > + Compulab SBC-iMX7 is a single board computer based on the > + Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with > + the CL-SOM-iMX7 System-on-Module providing most of the functions, > + and SB-SOM-iMX7 carrier board providing additional peripheral > + functions and connectors. > + items: > + - const: compulab,sbc-imx7 > + - const: compulab,cl-som-imx7 > + - const: fsl,imx7d > + > + - description: > + Freescale Vybrid Platform Device Tree Bindings > + > + For the Vybrid SoC familiy all variants with DDR controller are supported, > + which is the VF5xx and VF6xx series. Out of historical reasons, in most > + places the kernel uses vf610 to refer to the whole familiy. > + The compatible string "fsl,vf610m4" is used for the secondary Cortex-M4 > + core support. > + items: > + - enum: > + - fsl,vf500 > + - fsl,vf510 > + - fsl,vf600 > + - fsl,vf610 > + - fsl,vf610m4 > + > + - description: LS1021A based Boards > + items: > + - enum: > + - fsl,ls1012a-rdb > + - fsl,ls1012a-frdm > + - fsl,ls1012a-qds > + - const: fsl,ls1021a > + > + - description: LS1043A based Boards > + items: > + - enum: > + - fsl,ls1043a-rdb > + - fsl,ls1043a-qds > + - const: fsl,ls1043a > + > + - description: LS1046A based Boards > + items: > + - enum: > + - fsl,ls1046a-qds > + - fsl,ls1046a-rdb > + - const: fsl,ls1046a > + > + - description: LS1088A based Boards > + items: > + - enum: > + - fsl,ls1088a-qds > + - fsl,ls1088a-rdb > + - const: fsl,ls1088a > + > + - description: LS2080A based Boards > + items: > + - enum: > + - fsl,ls2080a-simu > + - fsl,ls2080a-qds > + - fsl,ls2080a-rdb > + - const: fsl,ls2080a > + > + - description: LS2088A based Boards > + items: > + - enum: > + - fsl,ls2088a-qds > + - fsl,ls2088a-rdb > + - const: fsl,ls2088a > + > +... > diff --git a/Documentation/devicetree/bindings/arm/i2se.txt b/Documentation/devicetree/bindings/arm/i2se.txt > deleted file mode 100644 > index dbd54a3aa07d..000000000000 > --- a/Documentation/devicetree/bindings/arm/i2se.txt > +++ /dev/null > @@ -1,22 +0,0 @@ > -I2SE Device Tree Bindings > -------------------------- > - > -Duckbill Board > -Required root node properties: > - - compatible = "i2se,duckbill", "fsl,imx28"; > - > -Duckbill 2 Board > -Required root node properties: > - - compatible = "i2se,duckbill-2", "fsl,imx28"; > - > -Duckbill 2 485 Board > -Required root node properties: > - - compatible = "i2se,duckbill-2-485", "i2se,duckbill-2", "fsl,imx28"; > - > -Duckbill 2 EnOcean Board > -Required root node properties: > - - compatible = "i2se,duckbill-2-enocean", "i2se,duckbill-2", "fsl,imx28"; > - > -Duckbill 2 SPI Board > -Required root node properties: > - - compatible = "i2se,duckbill-2-spi", "i2se,duckbill-2", "fsl,imx28"; > diff --git a/Documentation/devicetree/bindings/arm/olimex.txt b/Documentation/devicetree/bindings/arm/olimex.txt > deleted file mode 100644 > index d726aeca56be..000000000000 > --- a/Documentation/devicetree/bindings/arm/olimex.txt > +++ /dev/null > @@ -1,10 +0,0 @@ > -Olimex Device Tree Bindings > ---------------------------- > - > -SAM9-L9260 Board > -Required root node properties: > - - compatible = "olimex,sam9-l9260", "atmel,at91sam9260"; > - > -i.MX23 Olinuxino Low Cost Board > -Required root node properties: > - - compatible = "olimex,imx23-olinuxino", "fsl,imx23"; > diff --git a/Documentation/devicetree/bindings/arm/technologic.txt b/Documentation/devicetree/bindings/arm/technologic.txt > deleted file mode 100644 > index f1cedc00dcab..000000000000 > --- a/Documentation/devicetree/bindings/arm/technologic.txt > +++ /dev/null > @@ -1,23 +0,0 @@ > -Technologic Systems Platforms Device Tree Bindings > --------------------------------------------------- > - > -TS-4600 is a System-on-Module based on the Freescale i.MX28 System-on-Chip. > -It can be mounted on a carrier board providing additional peripheral connectors. > -Required root node properties: > - - compatible = "technologic,imx28-ts4600", "fsl,imx28" > - > -TS-4800 board > -Required root node properties: > - - compatible = "technologic,imx51-ts4800", "fsl,imx51"; > - > -TS-4900 is a System-on-Module based on the Freescale i.MX6 System-on-Chip. > -It can be mounted on a carrier board providing additional peripheral connectors. > -Required root node properties: > - - compatible = "technologic,imx6dl-ts4900", "fsl,imx6dl" > - - compatible = "technologic,imx6q-ts4900", "fsl,imx6q" > - > -TS-7970 is a System-on-Module based on the Freescale i.MX6 System-on-Chip. > -It can be mounted on a carrier board providing additional peripheral connectors. > -Required root node properties: > - - compatible = "technologic,imx6dl-ts7970", "fsl,imx6dl" > - - compatible = "technologic,imx6q-ts7970", "fsl,imx6q" > -- > 2.17.1 >
Hi Rob, On Fri, Oct 5, 2018 at 6:58 PM Rob Herring <robh@kernel.org> wrote: > In preparation to convert board-level bindings to json-schema, move > various misc SoC bindings out to their own file. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Simon Horman <horms@verge.net.au> > Cc: Magnus Damm <magnus.damm@gmail.com> > Cc: devicetree@vger.kernel.org > Cc: linux-renesas-soc@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Looks good to me, but needs a rebase, as the PRR section has been extended in -next. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Fri, Oct 05, 2018 at 11:58:48AM -0500, Rob Herring wrote: > Convert ZTE SoC bindings to DT schema format using json-schema. > > Cc: Jun Nie <jun.nie@linaro.org> > Cc: Baoyou Xie <baoyou.xie@linaro.org> > Cc: Shawn Guo <shawnguo@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-arm-kernel@lists.infradead.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Shawn Guo <shawnguo@kernel.org>
Hi Rob, On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > Convert Renesas SoC bindings to DT schema format using json-schema. > > Cc: Simon Horman <horms@verge.net.au> > Cc: Magnus Damm <magnus.damm@gmail.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-renesas-soc@vger.kernel.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Thanks for your patch! Note that this will need a rebase, as more SoCs/boards have been added in -next. > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > @@ -0,0 +1,205 @@ > +# SPDX-License-Identifier: None The old file didn't have an SPDX header, so it was GPL-2.0, implicitly? > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/shmobile.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > + > +maintainers: > + - Geert Uytterhoeven <geert+renesas@glider.be> Simon Horman <horms@verge.net.au> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) Magnus Damm <magnus.damm@gmail.com> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) You had it right in the CC list, though... > + - description: RZ/G1M (R8A77430) > + items: > + - enum: > + # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > + - iwave,g20d > + - const: iwave,g20m > + - const: renesas,r8a7743 > + > + - items: > + - enum: > + # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > + - iwave,g20m > + - const: renesas,r8a7743 > + > + - description: RZ/G1N (R8A77440) > + items: > + - enum: > + - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE) This board belongs under the RZ/G1M section above (see also the 7743 in the part number). > + - const: renesas,r8a7744 > + - description: Kingfisher (SBEV-RCAR-KF-M03) > + items: > + - const: shimafuji,kingfisher > + - enum: > + - renesas,h3ulcb > + - renesas,m3ulcb > + - enum: > + - renesas,r8a7795 > + - renesas,r8a7796 This looks a bit funny: all other entries have the "const" last, and use it for the SoC number. May be correct, though. To clarify, this is an extension board that can fit both the [HM]3ULCB boards (actually also the new M3NULCB, I think). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Fri, Oct 05, 2018 at 11:58:41AM -0500, Rob Herring wrote: > Convert Renesas SoC bindings to DT schema format using json-schema. > > Cc: Simon Horman <horms@verge.net.au> > Cc: Magnus Damm <magnus.damm@gmail.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-renesas-soc@vger.kernel.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> This seems fine to me other than that it does not seem to apply cleanly to next. shmobile.txt sees a couple of updates per release cycle so from my point of view it would ideal if this change could hit -rc1 to allow patches for v4.21 to be accepted smoothly (already one from Sergei will need rebasing). > --- > .../devicetree/bindings/arm/shmobile.txt | 143 ------------ > .../devicetree/bindings/arm/shmobile.yaml | 205 ++++++++++++++++++ > 2 files changed, 205 insertions(+), 143 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml > > diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt > deleted file mode 100644 > index 619b765e5bee..000000000000 > --- a/Documentation/devicetree/bindings/arm/shmobile.txt > +++ /dev/null > @@ -1,143 +0,0 @@ > -Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > --------------------------------------------------------------------- > - > -SoCs: > - > - - Emma Mobile EV2 > - compatible = "renesas,emev2" > - - RZ/A1H (R7S72100) > - compatible = "renesas,r7s72100" > - - SH-Mobile AG5 (R8A73A00/SH73A0) > - compatible = "renesas,sh73a0" > - - R-Mobile APE6 (R8A73A40) > - compatible = "renesas,r8a73a4" > - - R-Mobile A1 (R8A77400) > - compatible = "renesas,r8a7740" > - - RZ/G1H (R8A77420) > - compatible = "renesas,r8a7742" > - - RZ/G1M (R8A77430) > - compatible = "renesas,r8a7743" > - - RZ/G1N (R8A77440) > - compatible = "renesas,r8a7744" > - - RZ/G1E (R8A77450) > - compatible = "renesas,r8a7745" > - - RZ/G1C (R8A77470) > - compatible = "renesas,r8a77470" > - - R-Car M1A (R8A77781) > - compatible = "renesas,r8a7778" > - - R-Car H1 (R8A77790) > - compatible = "renesas,r8a7779" > - - R-Car H2 (R8A77900) > - compatible = "renesas,r8a7790" > - - R-Car M2-W (R8A77910) > - compatible = "renesas,r8a7791" > - - R-Car V2H (R8A77920) > - compatible = "renesas,r8a7792" > - - R-Car M2-N (R8A77930) > - compatible = "renesas,r8a7793" > - - R-Car E2 (R8A77940) > - compatible = "renesas,r8a7794" > - - R-Car H3 (R8A77950) > - compatible = "renesas,r8a7795" > - - R-Car M3-W (R8A77960) > - compatible = "renesas,r8a7796" > - - R-Car M3-N (R8A77965) > - compatible = "renesas,r8a77965" > - - R-Car V3M (R8A77970) > - compatible = "renesas,r8a77970" > - - R-Car V3H (R8A77980) > - compatible = "renesas,r8a77980" > - - R-Car E3 (R8A77990) > - compatible = "renesas,r8a77990" > - - R-Car D3 (R8A77995) > - compatible = "renesas,r8a77995" > - - RZ/N1D (R9A06G032) > - compatible = "renesas,r9a06g032" > - > -Boards: > - > - - Alt (RTP0RC7794SEB00010S) > - compatible = "renesas,alt", "renesas,r8a7794" > - - APE6-EVM > - compatible = "renesas,ape6evm", "renesas,r8a73a4" > - - Atmark Techno Armadillo-800 EVA > - compatible = "renesas,armadillo800eva", "renesas,r8a7740" > - - Blanche (RTP0RC7792SEB00010S) > - compatible = "renesas,blanche", "renesas,r8a7792" > - - BOCK-W > - compatible = "renesas,bockw", "renesas,r8a7778" > - - Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01) > - compatible = "renesas,condor", "renesas,r8a77980" > - - Draak (RTP0RC77995SEB0010S) > - compatible = "renesas,draak", "renesas,r8a77995" > - - Eagle (RTP0RC77970SEB0010S) > - compatible = "renesas,eagle", "renesas,r8a77970" > - - Ebisu (RTP0RC77990SEB0010S) > - compatible = "renesas,ebisu", "renesas,r8a77990" > - - Genmai (RTK772100BC00000BR) > - compatible = "renesas,genmai", "renesas,r7s72100" > - - GR-Peach (X28A-M01-E/F) > - compatible = "renesas,gr-peach", "renesas,r7s72100" > - - Gose (RTP0RC7793SEB00010S) > - compatible = "renesas,gose", "renesas,r8a7793" > - - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > - H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) > - compatible = "renesas,h3ulcb", "renesas,r8a7795" > - - Henninger > - compatible = "renesas,henninger", "renesas,r8a7791" > - - iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > - compatible = "iwave,g23s", "renesas,r8a77470" > - - iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D) > - compatible = "iwave,g22d", "iwave,g22m", "renesas,r8a7745" > - - iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM) > - compatible = "iwave,g22m", "renesas,r8a7745" > - - iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > - compatible = "iwave,g20d", "iwave,g20m", "renesas,r8a7743" > - - iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > - compatible = "iwave,g20m", "renesas,r8a7743" > - - Kingfisher (SBEV-RCAR-KF-M03) > - compatible = "shimafuji,kingfisher" > - - Koelsch (RTP0RC7791SEB00010S) > - compatible = "renesas,koelsch", "renesas,r8a7791" > - - Kyoto Microcomputer Co. KZM-A9-Dual > - compatible = "renesas,kzm9d", "renesas,emev2" > - - Kyoto Microcomputer Co. KZM-A9-GT > - compatible = "renesas,kzm9g", "renesas,sh73a0" > - - Lager (RTP0RC7790SEB00010S) > - compatible = "renesas,lager", "renesas,r8a7790" > - - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > - compatible = "renesas,m3ulcb", "renesas,r8a7796" > - - Marzen (R0P7779A00010S) > - compatible = "renesas,marzen", "renesas,r8a7779" > - - Porter (M2-LCDP) > - compatible = "renesas,porter", "renesas,r8a7791" > - - RSKRZA1 (YR0K77210C000BE) > - compatible = "renesas,rskrza1", "renesas,r7s72100" > - - RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) > - compatible = "renesas,rzn1d400-db", "renesas,r9a06g032" > - - Salvator-X (RTP0RC7795SIPB0010S) > - compatible = "renesas,salvator-x", "renesas,r8a7795" > - - Salvator-X (RTP0RC7796SIPB0011S) > - compatible = "renesas,salvator-x", "renesas,r8a7796" > - - Salvator-X (RTP0RC7796SIPB0011S (M3-N)) > - compatible = "renesas,salvator-x", "renesas,r8a77965" > - - Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) > - compatible = "renesas,salvator-xs", "renesas,r8a7795" > - - Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S) > - compatible = "renesas,salvator-xs", "renesas,r8a7796" > - - Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S) > - compatible = "renesas,salvator-xs", "renesas,r8a77965" > - - SILK (RTP0RC7794LCB00011S) > - compatible = "renesas,silk", "renesas,r8a7794" > - - SK-RZG1E (YR8A77450S000BE) > - compatible = "renesas,sk-rzg1e", "renesas,r8a7745" > - - SK-RZG1M (YR8A77430S000BE) > - compatible = "renesas,sk-rzg1m", "renesas,r8a7743" > - - Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD) > - compatible = "renesas,stout", "renesas,r8a7790" > - - V3HSK (Y-ASK-RCAR-V3H-WS10) > - compatible = "renesas,v3hsk", "renesas,r8a77980" > - - V3MSK (Y-ASK-RCAR-V3M-WS10) > - compatible = "renesas,v3msk", "renesas,r8a77970" > - - Wheat (RTP0RC7792ASKB0000JE) > - compatible = "renesas,wheat", "renesas,r8a7792" > diff --git a/Documentation/devicetree/bindings/arm/shmobile.yaml b/Documentation/devicetree/bindings/arm/shmobile.yaml > new file mode 100644 > index 000000000000..31009e7fb0ea > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > @@ -0,0 +1,205 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/shmobile.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > + > +maintainers: > + - Geert Uytterhoeven <geert+renesas@glider.be> > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - description: Emma Mobile EV2 > + items: > + - enum: > + - renesas,kzm9d # Kyoto Microcomputer Co. KZM-A9-Dual > + - const: renesas,emev2 > + > + - description: RZ/A1H (R7S72100) > + items: > + - enum: > + - renesas,genmai # Genmai (RTK772100BC00000BR) > + - renesas,gr-peach # GR-Peach (X28A-M01-E/F) > + - renesas,rskrza1 # RSKRZA1 (YR0K77210C000BE) > + - const: renesas,r7s72100 > + > + - description: SH-Mobile AG5 (R8A73A00/SH73A0) > + items: > + - enum: > + - renesas,kzm9g # Kyoto Microcomputer Co. KZM-A9-GT > + - const: renesas,sh73a0 > + > + - description: R-Mobile APE6 (R8A73A40) > + items: > + - enum: > + - renesas,ape6evm > + - const: renesas,r8a73a4 > + > + - description: R-Mobile A1 (R8A77400) > + items: > + - enum: > + - renesas,armadillo800eva # Atmark Techno Armadillo-800 EVA > + - const: renesas,r8a7740 > + > + - description: RZ/G1H (R8A77420) > + items: > + - const: renesas,r8a7742 > + > + - description: RZ/G1M (R8A77430) > + items: > + - enum: > + # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > + - iwave,g20d > + - const: iwave,g20m > + - const: renesas,r8a7743 > + > + - items: > + - enum: > + # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > + - iwave,g20m > + - const: renesas,r8a7743 > + > + - description: RZ/G1N (R8A77440) > + items: > + - enum: > + - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE) > + - const: renesas,r8a7744 > + > + - description: RZ/G1E (R8A77450) > + items: > + - enum: > + - iwave,g22m # iWave Systems RZ/G1E SODIMM System On Module (iW-RainboW-G22M-SM) > + - renesas,sk-rzg1e # SK-RZG1E (YR8A77450S000BE) > + - const: renesas,r8a7745 > + - items: > + # iWave Systems RZ/G1E SODIMM SOM Development Platform (iW-RainboW-G22D) > + - const: iwave,g22d > + - const: iwave,g22m > + - const: renesas,r8a7745 > + > + - description: RZ/G1C (R8A77470) > + items: > + - enum: > + - iwave,g23s #iWave Systems RZ/G1C Single Board Computer (iW-RainboW-G23S) > + - const: renesas,r8a77470 > + > + - description: R-Car M1A (R8A77781) > + items: > + - enum: > + - renesas,bockw > + - const: renesas,r8a7778 > + > + - description: R-Car H1 (R8A77790) > + items: > + - enum: > + - renesas,marzen # Marzen (R0P7779A00010S) > + - renesas,stout # Stout (ADAS Starterkit, Y-R-CAR-ADAS-SKH2-BOARD) > + - const: renesas,r8a7779 > + > + - description: R-Car H2 (R8A77900) > + items: > + - enum: > + - renesas,lager # Lager (RTP0RC7790SEB00010S) > + - const: renesas,r8a7790 > + > + - description: R-Car M2-W (R8A77910) > + items: > + - enum: > + - renesas,henninger > + - renesas,koelsch # Koelsch (RTP0RC7791SEB00010S) > + - renesas,porter # Porter (M2-LCDP) > + - const: renesas,r8a7791 > + > + - description: R-Car V2H (R8A77920) > + items: > + - enum: > + - renesas,blanche # Blanche (RTP0RC7792SEB00010S) > + - renesas,wheat # Wheat (RTP0RC7792ASKB0000JE) > + - const: renesas,r8a7792 > + > + - description: R-Car M2-N (R8A77930) > + items: > + - enum: > + - renesas,gose # Gose (RTP0RC7793SEB00010S) > + - const: renesas,r8a7793 > + > + - description: R-Car E2 (R8A77940) > + items: > + - enum: > + - renesas,alt # Alt (RTP0RC7794SEB00010S) > + - renesas,silk # SILK (RTP0RC7794LCB00011S) > + - const: renesas,r8a7794 > + > + - description: R-Car H3 (R8A77950) > + items: > + - enum: > + # H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) > + # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) > + - renesas,h3ulcb > + - renesas,salvator-x # Salvator-X (RTP0RC7795SIPB0010S) > + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) > + - const: renesas,r8a7795 > + > + - description: R-Car M3-W (R8A77960) > + items: > + - enum: > + - renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0)) > + - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S) > + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S) > + - const: renesas,r8a7796 > + > + - description: Kingfisher (SBEV-RCAR-KF-M03) > + items: > + - const: shimafuji,kingfisher > + - enum: > + - renesas,h3ulcb > + - renesas,m3ulcb > + - enum: > + - renesas,r8a7795 > + - renesas,r8a7796 > + > + - description: R-Car M3-N (R8A77965) > + items: > + - enum: > + - renesas,salvator-x # Salvator-X (RTP0RC7796SIPB0011S (M3-N)) > + - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC77965SIPB012S) > + - const: renesas,r8a77965 > + > + - description: R-Car V3M (R8A77970) > + items: > + - enum: > + - renesas,eagle # Eagle (RTP0RC77970SEB0010S) > + - renesas,v3msk # V3MSK (Y-ASK-RCAR-V3M-WS10) > + - const: renesas,r8a77970 > + > + - description: R-Car V3H (R8A77980) > + items: > + - enum: > + - renesas,condor # Condor (RTP0RC77980SEB0010SS/RTP0RC77980SEB0010SA01) > + - renesas,v3hsk # V3HSK (Y-ASK-RCAR-V3H-WS10) > + - const: renesas,r8a77980 > + > + - description: R-Car E3 (R8A77990) > + items: > + - enum: > + - renesas,ebisu # Ebisu (RTP0RC77990SEB0010S) > + - const: renesas,r8a77990 > + > + - description: R-Car D3 (R8A77995) > + items: > + - enum: > + - renesas,draak # Draak (RTP0RC77995SEB0010S) > + - const: renesas,r8a77995 > + > + - description: RZ/N1D (R9A06G032) > + items: > + - enum: > + - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) > + - const: renesas,r9a06g032 > + > +... > -- > 2.17.1 >
On Mon, Oct 8, 2018 at 2:02 AM Shawn Guo <shawnguo@kernel.org> wrote: > > On Fri, Oct 05, 2018 at 11:58:34AM -0500, Rob Herring wrote: > > Convert Freescale SoC bindings to DT schema format using json-schema. > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - description: i.MX23 based Boards > > + items: > > + - enum: > > + - fsl,imx23-evk > > + - olimex,imx23-olinuxino > > + - const: fsl,imx23 > > + > > + - description: i.MX25 Product Development Kit > > + items: > > + - enum: > > + - fsl,imx25-pdk > > + - const: fsl,imx25 > > + > > + - description: i.MX27 Product Development Kit > > + items: > > + - enum: > > + - fsl,imx27-pdk > > + - const: fsl,imx27 > > + > > + - description: i.MX28 based Boards > > + items: > > + - enum: > > + - fsl,imx28-evk > > + - i2se,duckbill > > + - i2se,duckbill-2 > > + - technologic,imx28-ts4600 > > + - const: fsl,imx28 > > + - items: > > The schema is new to me. This line looks unusual to me, so you may want > to double check. It's fine. There's just no description schema on this one as it's a continuation of the previous one (logically, but not from a schema perspective). Perhaps add "i.MX28 I2SE Duckbill 2 based boards". > > + - enum: > > + - i2se,duckbill-2-485 > > + - i2se,duckbill-2-enocean > > + - i2se,duckbill-2-spi > > + - const: i2se,duckbill-2 > > + - const: fsl,imx28 > > + > > + - description: i.MX51 Babbage Board
On Mon, Oct 8, 2018 at 2:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Rob, > > On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > > Cc: Simon Horman <horms@verge.net.au> > > Cc: Magnus Damm <magnus.damm@gmail.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-renesas-soc@vger.kernel.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > Thanks for your patch! > > Note that this will need a rebase, as more SoCs/boards have been added > in -next. > > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > > @@ -0,0 +1,205 @@ > > +# SPDX-License-Identifier: None > > The old file didn't have an SPDX header, so it was GPL-2.0, implicitly? Right. I meant to update this with something. I'd prefer it be dual licensed as these aren't just kernel files, but I don't really want to try to gather permissions from all the copyright holders. And who is the copyright holder when it is implicit? Everyone listed by git blame? > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/bindings/arm/shmobile.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings > > + > > +maintainers: > > + - Geert Uytterhoeven <geert+renesas@glider.be> > > Simon Horman <horms@verge.net.au> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) > Magnus Damm <magnus.damm@gmail.com> (supporter:ARM/SHMOBILE ARM ARCHITECTURE) > > You had it right in the CC list, though... I generated it here from git log rather get_maintainers.pl because get_maintainers.pl just lists me for a bunch of them. > > + - description: RZ/G1M (R8A77430) > > + items: > > + - enum: > > + # iWave Systems RZ/G1M Qseven Development Platform (iW-RainboW-G20D-Qseven) > > + - iwave,g20d > > + - const: iwave,g20m > > + - const: renesas,r8a7743 > > + > > + - items: > > + - enum: > > + # iWave Systems RZ/G1M Qseven System On Module (iW-RainboW-G20M-Qseven) > > + - iwave,g20m > > + - const: renesas,r8a7743 > > + > > + - description: RZ/G1N (R8A77440) > > + items: > > + - enum: > > + - renesas,sk-rzg1m # SK-RZG1M (YR8A77430S000BE) > > This board belongs under the RZ/G1M section above > (see also the 7743 in the part number). Indeed. Not sure how I screwed that one up. > > + - const: renesas,r8a7744 > > > + - description: Kingfisher (SBEV-RCAR-KF-M03) > > + items: > > + - const: shimafuji,kingfisher > > + - enum: > > + - renesas,h3ulcb > > + - renesas,m3ulcb > > + - enum: > > + - renesas,r8a7795 > > + - renesas,r8a7796 > > This looks a bit funny: all other entries have the "const" last, and > use it for the > SoC number. May be correct, though. > To clarify, this is an extension board that can fit both the [HM]3ULCB > boards (actually also the new M3NULCB, I think). This being Kingfisher? I wrote this based on dts files in the tree. There's 2 combinations that I see: "shimafuji,kingfisher", "renesas,h3ulcb", "renesas,r8a7795" "shimafuji,kingfisher", "renesas,m3ulcb", "renesas,r8a7796" The schema allows 4 combinations (1 * 2 * 2). I have no idea if the other combinations are possible. If not, then we could rewrite this as 2 entries with 3 const values each. Rob
Hi Rob, On Mon, Oct 8, 2018 at 4:57 PM Rob Herring <robh@kernel.org> wrote: > On Mon, Oct 8, 2018 at 2:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > > > @@ -0,0 +1,205 @@ > > > + - description: Kingfisher (SBEV-RCAR-KF-M03) > > > + items: > > > + - const: shimafuji,kingfisher > > > + - enum: > > > + - renesas,h3ulcb > > > + - renesas,m3ulcb > > > + - enum: > > > + - renesas,r8a7795 > > > + - renesas,r8a7796 > > > > This looks a bit funny: all other entries have the "const" last, and > > use it for the > > SoC number. May be correct, though. > > To clarify, this is an extension board that can fit both the [HM]3ULCB > > boards (actually also the new M3NULCB, I think). > > This being Kingfisher? Correct. > I wrote this based on dts files in the tree. There's 2 combinations that I see: > > "shimafuji,kingfisher", "renesas,h3ulcb", "renesas,r8a7795" > "shimafuji,kingfisher", "renesas,m3ulcb", "renesas,r8a7796" > > The schema allows 4 combinations (1 * 2 * 2). I have no idea if the > other combinations are possible. If not, then we could rewrite this as > 2 entries with 3 const values each. I expect there will soon be a third one: "shimafuji,kingfisher", "renesas,m3nulcb", "renesas,r8a77965" Technically, {h3,m3,m3n}ulcb are the same board (although there may be minor revision differences), with a different SiP mounted. But they are called/marketed depending on which SiP is mounted. And on top of that, you can plug in a Kingfisher daughterboard. Could be an overlay ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, Oct 8, 2018 at 10:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Rob, > > On Mon, Oct 8, 2018 at 4:57 PM Rob Herring <robh@kernel.org> wrote: > > On Mon, Oct 8, 2018 at 2:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Fri, Oct 5, 2018 at 6:59 PM Rob Herring <robh@kernel.org> wrote: > > > > Convert Renesas SoC bindings to DT schema format using json-schema. > > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/arm/shmobile.yaml > > > > @@ -0,0 +1,205 @@ > > > > > + - description: Kingfisher (SBEV-RCAR-KF-M03) > > > > + items: > > > > + - const: shimafuji,kingfisher > > > > + - enum: > > > > + - renesas,h3ulcb > > > > + - renesas,m3ulcb > > > > + - enum: > > > > + - renesas,r8a7795 > > > > + - renesas,r8a7796 > > > > > > This looks a bit funny: all other entries have the "const" last, and > > > use it for the > > > SoC number. May be correct, though. > > > To clarify, this is an extension board that can fit both the [HM]3ULCB > > > boards (actually also the new M3NULCB, I think). > > > > This being Kingfisher? > > Correct. > > > I wrote this based on dts files in the tree. There's 2 combinations that I see: > > > > "shimafuji,kingfisher", "renesas,h3ulcb", "renesas,r8a7795" > > "shimafuji,kingfisher", "renesas,m3ulcb", "renesas,r8a7796" > > > > The schema allows 4 combinations (1 * 2 * 2). I have no idea if the > > other combinations are possible. If not, then we could rewrite this as > > 2 entries with 3 const values each. > > I expect there will soon be a third one: > > "shimafuji,kingfisher", "renesas,m3nulcb", "renesas,r8a77965" > > Technically, {h3,m3,m3n}ulcb are the same board (although there may be > minor revision differences), with a different SiP mounted. > But they are called/marketed depending on which SiP is mounted. > > And on top of that, you can plug in a Kingfisher daughterboard. Could be an > overlay ;-) We probably shouldn't have put kingfisher as a top-level compatible then. But we did, so not really much point to discuss that now. As to whether there's a better way to express it in the schema, I'm not sure. I don't think there's a way with json-schema to express a list, but the 1st item is optional. Rob
Hi Rob, On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > Convert ARM PMU binding to DT schema format using json-schema. > > Cc: Will Deacon <will.deacon@arm.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-arm-kernel@lists.infradead.org > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > 2 files changed, 96 insertions(+), 70 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml [...] > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > - interrupt (PPI) then 1 interrupt should be specified. [...] > + interrupts: > + oneOf: > + - maxItems: 1 > + - minItems: 2 > + maxItems: 8 > + description: 1 interrupt per core. > + > + interrupts-extended: > + $ref: '#/properties/interrupts' This seems like a semantic different between the two representations, or am I missing something here? Specifically, both the introduction of interrupts-extended and also dropping any mention of using a single per-cpu interrupt (the single combined case is no longer support by Linux; not sure if you want to keep it in the binding). Will
On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > Hi Rob, > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > Convert ARM PMU binding to DT schema format using json-schema. > > > > Cc: Will Deacon <will.deacon@arm.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > 2 files changed, 96 insertions(+), 70 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > [...] > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > - interrupt (PPI) then 1 interrupt should be specified. > > [...] > > > + interrupts: > > + oneOf: > > + - maxItems: 1 > > + - minItems: 2 > > + maxItems: 8 > > + description: 1 interrupt per core. > > + > > + interrupts-extended: > > + $ref: '#/properties/interrupts' > > This seems like a semantic different between the two representations, or am > I missing something here? Specifically, both the introduction of > interrupts-extended and also dropping any mention of using a single per-cpu > interrupt (the single combined case is no longer support by Linux; not sure > if you want to keep it in the binding). 'interrupts-extended' was implied before as it is always supported and outside the scope of the binding. But now it is needed to validate bindings. There must be some use of it and that's why I added it. However, thinking some more about this, I think it may be better to have the tools add this in automatically whenever we have an interrupts property. I guess the single interrupt case is less obvious now with no description (it's the first list item of 'oneOf'). The schema If the single interrupt is not supported, then we can drop it here. Rob
Hi Rob On 10/05/2018 06:58 PM, Rob Herring wrote: > Convert ST STi SoC bindings to DT schema format using json-schema. > > Cc: Patrice Chotard <patrice.chotard@st.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > Documentation/devicetree/bindings/arm/sti.txt | 23 ------------------- > .../devicetree/bindings/arm/sti.yaml | 23 +++++++++++++++++++ > 2 files changed, 23 insertions(+), 23 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/sti.txt > create mode 100644 Documentation/devicetree/bindings/arm/sti.yaml > > diff --git a/Documentation/devicetree/bindings/arm/sti.txt b/Documentation/devicetree/bindings/arm/sti.txt > deleted file mode 100644 > index 8d27f6b084c7..000000000000 > --- a/Documentation/devicetree/bindings/arm/sti.txt > +++ /dev/null > @@ -1,23 +0,0 @@ > -ST STi Platforms Device Tree Bindings > ---------------------------------------- > - > -Boards with the ST STiH415 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih415"; > - > -Boards with the ST STiH416 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih416"; > - > -Boards with the ST STiH407 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih407"; > - > -Boards with the ST STiH410 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih410"; > - > -Boards with the ST STiH418 SoC shall have the following properties: > -Required root node property: > -compatible = "st,stih418"; > - > diff --git a/Documentation/devicetree/bindings/arm/sti.yaml b/Documentation/devicetree/bindings/arm/sti.yaml > new file mode 100644 > index 000000000000..10814334cfc9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/sti.yaml > @@ -0,0 +1,23 @@ > +# SPDX-License-Identifier: None > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/sti.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ST STi Platforms Device Tree Bindings > + > +maintainers: > + - Maxime Coquelin <maxime.coquelin@st.com> Maxime has left STMicroelectronics, you can replace its email by mine Patrice Chotard <patrice.chotard@st.com> Thanks Patrice > + > +properties: > + $nodename: > + const: '/' > + compatible: > + items: > + - enum: > + - st,stih415 > + - st,stih416 > + - st,stih407 > + - st,stih410 > + - st,stih418 > +... >
On Tue, Oct 09, 2018 at 01:14:02PM -0500, Rob Herring wrote: > On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > > > Hi Rob, > > > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > > Convert ARM PMU binding to DT schema format using json-schema. > > > > > > Cc: Will Deacon <will.deacon@arm.com> > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: linux-arm-kernel@lists.infradead.org > > > Cc: devicetree@vger.kernel.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > > 2 files changed, 96 insertions(+), 70 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > > > [...] > > > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > > - interrupt (PPI) then 1 interrupt should be specified. > > > > [...] > > > > > + interrupts: > > > + oneOf: > > > + - maxItems: 1 > > > + - minItems: 2 > > > + maxItems: 8 > > > + description: 1 interrupt per core. > > > + > > > + interrupts-extended: > > > + $ref: '#/properties/interrupts' > > > > This seems like a semantic different between the two representations, or am > > I missing something here? Specifically, both the introduction of > > interrupts-extended and also dropping any mention of using a single per-cpu > > interrupt (the single combined case is no longer support by Linux; not sure > > if you want to keep it in the binding). > > 'interrupts-extended' was implied before as it is always supported and > outside the scope of the binding. But now it is needed to validate > bindings. There must be some use of it and that's why I added it. > However, thinking some more about this, I think it may be better to > have the tools add this in automatically whenever we have an > interrupts property. To be honest, if you'd included that in the commit message I'd have been happy :) > I guess the single interrupt case is less obvious now with no > description (it's the first list item of 'oneOf'). The schema If the > single interrupt is not supported, then we can drop it here. Well the description says "1 interrupt per core" which is incorrect. I also don't understand why maxItems is 8. Will
On Wed, Oct 10, 2018 at 11:50 AM Will Deacon <will.deacon@arm.com> wrote: > > On Tue, Oct 09, 2018 at 01:14:02PM -0500, Rob Herring wrote: > > On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > > > > > Hi Rob, > > > > > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > > > Convert ARM PMU binding to DT schema format using json-schema. > > > > > > > > Cc: Will Deacon <will.deacon@arm.com> > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > > Cc: linux-arm-kernel@lists.infradead.org > > > > Cc: devicetree@vger.kernel.org > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > --- > > > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > > > 2 files changed, 96 insertions(+), 70 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > > > > > [...] > > > > > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > > > - interrupt (PPI) then 1 interrupt should be specified. > > > > > > [...] > > > > > > > + interrupts: > > > > + oneOf: > > > > + - maxItems: 1 > > > > + - minItems: 2 > > > > + maxItems: 8 > > > > + description: 1 interrupt per core. > > > > + > > > > + interrupts-extended: > > > > + $ref: '#/properties/interrupts' > > > > > > This seems like a semantic different between the two representations, or am > > > I missing something here? Specifically, both the introduction of > > > interrupts-extended and also dropping any mention of using a single per-cpu > > > interrupt (the single combined case is no longer support by Linux; not sure > > > if you want to keep it in the binding). > > > > 'interrupts-extended' was implied before as it is always supported and > > outside the scope of the binding. But now it is needed to validate > > bindings. There must be some use of it and that's why I added it. > > However, thinking some more about this, I think it may be better to > > have the tools add this in automatically whenever we have an > > interrupts property. > > To be honest, if you'd included that in the commit message I'd have been > happy :) > > > I guess the single interrupt case is less obvious now with no > > description (it's the first list item of 'oneOf'). The schema If the > > single interrupt is not supported, then we can drop it here. > > Well the description says "1 interrupt per core" which is incorrect. You are reading the schema wrong. There are 2 cases supported as defined by each '-'. The 2nd case is all the keywords until the indentation decreases. So 'description' is just description of the 2nd case. The first case is just "maxItems: 1". I probably didn't put a description because why write in free form text what the schema says (other than of course no one knows json-schema...). YAML combines the best of Makefiles and python. You can't have tabs and Indentation is significant. :) > I also > don't understand why maxItems is 8. Humm, I probably just made that up based on GICv2 limitations. What should it be? If there's not any inherit maximum, can we put something reasonable? There's not really any way to express that it should match the number of cores in the system. Rob
Hi Rob, On Wed, Oct 10, 2018 at 01:51:24PM -0500, Rob Herring wrote: > On Wed, Oct 10, 2018 at 11:50 AM Will Deacon <will.deacon@arm.com> wrote: > > On Tue, Oct 09, 2018 at 01:14:02PM -0500, Rob Herring wrote: > > > I guess the single interrupt case is less obvious now with no > > > description (it's the first list item of 'oneOf'). The schema If the > > > single interrupt is not supported, then we can drop it here. > > > > Well the description says "1 interrupt per core" which is incorrect. > > You are reading the schema wrong. There are 2 cases supported as > defined by each '-'. The 2nd case is all the keywords until the > indentation decreases. So 'description' is just description of the 2nd > case. The first case is just "maxItems: 1". I probably didn't put a > description because why write in free form text what the schema says > (other than of course no one knows json-schema...). Apologies, I've not read one of these things before and looks like I completely misread it. > YAML combines the best of Makefiles and python. You can't have tabs > and Indentation is significant. :) Oh wow, I'm in way over my head here! > > I also > > don't understand why maxItems is 8. > > Humm, I probably just made that up based on GICv2 limitations. What > should it be? If there's not any inherit maximum, can we put something > reasonable? There's not really any way to express that it should match > the number of cores in the system. What's the largest number you can think of? Will
On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: > > Hi Rob, > > On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: > > Convert ARM PMU binding to DT schema format using json-schema. > > > > Cc: Will Deacon <will.deacon@arm.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- > > .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ > > 2 files changed, 96 insertions(+), 70 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt > > create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml > > [...] > > > -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu > > - interrupt (PPI) then 1 interrupt should be specified. > > [...] > > > + interrupts: > > + oneOf: > > + - maxItems: 1 > > + - minItems: 2 > > + maxItems: 8 > > + description: 1 interrupt per core. > > + > > + interrupts-extended: > > + $ref: '#/properties/interrupts' > > This seems like a semantic different between the two representations, or am > I missing something here? Specifically, both the introduction of > interrupts-extended and also dropping any mention of using a single per-cpu > interrupt (the single combined case is no longer support by Linux; not sure > if you want to keep it in the binding). In regards to no support for the single combined interrupt, it looks like Marvell Armada SoCs at least (armada-375 is what I'm looking at) have only a single interrupt. Though the interrupt gets routed to MPIC which then has a GIC PPI. So it isn't supported or happens to work still since it is a PPI? Rob
On 05. 10. 18 18:58, Rob Herring wrote: > Convert Xilinx SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Michal Simek <michal.simek@xilinx.com> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/xilinx.txt | 83 ------------------- > .../devicetree/bindings/arm/xilinx.yaml | 81 ++++++++++++++++++ > 2 files changed, 81 insertions(+), 83 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/xilinx.txt > create mode 100644 Documentation/devicetree/bindings/arm/xilinx.yaml > > diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt > deleted file mode 100644 > index 26fe5ecc4332..000000000000 > --- a/Documentation/devicetree/bindings/arm/xilinx.txt > +++ /dev/null > @@ -1,83 +0,0 @@ > -Xilinx Zynq Platforms Device Tree Bindings > - > -Boards with Zynq-7000 SOC based on an ARM Cortex A9 processor > -shall have the following properties. > - > -Required root node properties: > - - compatible = "xlnx,zynq-7000"; > - > -Additional compatible strings: > - > -- Adapteva Parallella board > - "adapteva,parallella" > - > -- Avnet MicroZed board > - "avnet,zynq-microzed" > - "xlnx,zynq-microzed" > - > -- Avnet ZedBoard board > - "avnet,zynq-zed" > - "xlnx,zynq-zed" > - > -- Digilent Zybo board > - "digilent,zynq-zybo" > - > -- Digilent Zybo Z7 board > - "digilent,zynq-zybo-z7" > - > -- Xilinx CC108 internal board > - "xlnx,zynq-cc108" > - > -- Xilinx ZC702 internal board > - "xlnx,zynq-zc702" > - > -- Xilinx ZC706 internal board > - "xlnx,zynq-zc706" > - > -- Xilinx ZC770 internal board, with different FMC cards > - "xlnx,zynq-zc770-xm010" > - "xlnx,zynq-zc770-xm011" > - "xlnx,zynq-zc770-xm012" > - "xlnx,zynq-zc770-xm013" > - > ---------------------------------------------------------------- > - > -Xilinx Zynq UltraScale+ MPSoC Platforms Device Tree Bindings > - > -Boards with ZynqMP SOC based on an ARM Cortex A53 processor > -shall have the following properties. > - > -Required root node properties: > - - compatible = "xlnx,zynqmp"; > - > - > -Additional compatible strings: > - > -- Xilinx internal board zc1232 > - "xlnx,zynqmp-zc1232-revA", "xlnx,zynqmp-zc1232" > - > -- Xilinx internal board zc1254 > - "xlnx,zynqmp-zc1254-revA", "xlnx,zynqmp-zc1254" > - > -- Xilinx internal board zc1275 > - "xlnx,zynqmp-zc1275-revA", "xlnx,zynqmp-zc1275" > - > -- Xilinx internal board zc1751 > - "xlnx,zynqmp-zc1751" > - > -- Xilinx 96boards compatible board zcu100 > - "xlnx,zynqmp-zcu100-revC", "xlnx,zynqmp-zcu100" > - > -- Xilinx evaluation board zcu102 > - "xlnx,zynqmp-zcu102-revA", "xlnx,zynqmp-zcu102" > - "xlnx,zynqmp-zcu102-revB", "xlnx,zynqmp-zcu102" > - "xlnx,zynqmp-zcu102-rev1.0", "xlnx,zynqmp-zcu102" > - > -- Xilinx evaluation board zcu104 > - "xlnx,zynqmp-zcu104-revA", "xlnx,zynqmp-zcu104" > - > -- Xilinx evaluation board zcu106 > - "xlnx,zynqmp-zcu106-revA", "xlnx,zynqmp-zcu106" > - > -- Xilinx evaluation board zcu111 > - "xlnx,zynqmp-zcu111-revA", "xlnx,zynqmp-zcu111" > diff --git a/Documentation/devicetree/bindings/arm/xilinx.yaml b/Documentation/devicetree/bindings/arm/xilinx.yaml > new file mode 100644 > index 000000000000..dd227bccf015 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/xilinx.yaml > @@ -0,0 +1,81 @@ > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/arm/xilinx.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Xilinx Zynq Platforms Device Tree Bindings > + > +maintainers: > + - Michal Simek <michal.simek@xilinx.com> > + > +description: | > + Xilinx boards with Zynq-7000 SOC or Zynq UltraScale+ MPSoC > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - enum: > + - adapteva,parallella > + - digilent,zynq-zybo > + - digilent,zynq-zybo-z7 > + - xlnx,zynq-cc108 > + - xlnx,zynq-zc702 > + - xlnx,zynq-zc706 > + - xlnx,zynq-zc770-xm010 > + - xlnx,zynq-zc770-xm011 > + - xlnx,zynq-zc770-xm012 > + - xlnx,zynq-zc770-xm013 > + - const: xlnx,zynq-7000 > + > + - items: > + - const: avnet,zynq-microzed > + - const: xlnx,zynq-microzed > + - const: xlnx,zynq-7000 > + > + - items: > + - const: avnet,zynq-zed > + - const: xlnx,zynq-zed > + - const: xlnx,zynq-7000 > + > + - items: > + - enum: > + - xlnx,zynqmp-zc1751 > + - const: xlnx,zynqmp > + > + - description: Xilinx internal board zc1232 > + items: > + - const: xlnx,zynqmp-zc1232-revA > + - const: xlnx,zynqmp-zc1232 > + - const: xlnx,zynqmp > + > + - description: Xilinx internal board zc1254 > + items: > + - const: xlnx,zynqmp-zc1254-revA > + - const: xlnx,zynqmp-zc1254 > + - const: xlnx,zynqmp > + > + - description: Xilinx internal board zc1275 > + items: > + - const: xlnx,zynqmp-zc1275-revA > + - const: xlnx,zynqmp-zc1275 > + - const: xlnx,zynqmp > + > + - description: Xilinx 96boards compatible board zcu100 > + items: > + - const: xlnx,zynqmp-zcu100-revC > + - const: xlnx,zynqmp-zcu100 > + - const: xlnx,zynqmp > + > + - description: Xilinx evaluation board zcu102 > + items: > + - enum: > + - xlnx,zynqmp-zcu102-revA > + - xlnx,zynqmp-zcu102-revB > + - xlnx,zynqmp-zcu102-rev1.0 > + - const: xlnx,zynqmp-zcu102 > + - const: xlnx,zynqmp > + > +... > Conversion looks good. I have also found that we are missing some boards when I was playing with your branch. But this can be added on the top of this patch. I have sent you separate patch for that. Also I have found that we are missing one property which can go to the tree directly and I am going to send a patch for it too. Acked-by: Michal Simek <michal.simek@xilinx.com> Thanks, Michal
On 01/11/2018 19:32, Rob Herring wrote: > On Tue, Oct 9, 2018 at 6:57 AM Will Deacon <will.deacon@arm.com> wrote: >> >> Hi Rob, >> >> On Fri, Oct 05, 2018 at 11:58:25AM -0500, Rob Herring wrote: >>> Convert ARM PMU binding to DT schema format using json-schema. >>> >>> Cc: Will Deacon <will.deacon@arm.com> >>> Cc: Mark Rutland <mark.rutland@arm.com> >>> Cc: linux-arm-kernel@lists.infradead.org >>> Cc: devicetree@vger.kernel.org >>> Signed-off-by: Rob Herring <robh@kernel.org> >>> --- >>> Documentation/devicetree/bindings/arm/pmu.txt | 70 -------------- >>> .../devicetree/bindings/arm/pmu.yaml | 96 +++++++++++++++++++ >>> 2 files changed, 96 insertions(+), 70 deletions(-) >>> delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt >>> create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml >> >> [...] >> >>> -- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu >>> - interrupt (PPI) then 1 interrupt should be specified. >> >> [...] >> >>> + interrupts: >>> + oneOf: >>> + - maxItems: 1 >>> + - minItems: 2 >>> + maxItems: 8 >>> + description: 1 interrupt per core. >>> + >>> + interrupts-extended: >>> + $ref: '#/properties/interrupts' >> >> This seems like a semantic different between the two representations, or am >> I missing something here? Specifically, both the introduction of >> interrupts-extended and also dropping any mention of using a single per-cpu >> interrupt (the single combined case is no longer support by Linux; not sure >> if you want to keep it in the binding). > > In regards to no support for the single combined interrupt, it looks > like Marvell Armada SoCs at least (armada-375 is what I'm looking at) > have only a single interrupt. Though the interrupt gets routed to MPIC > which then has a GIC PPI. So it isn't supported or happens to work > still since it is a PPI? Well, the description of the MPIC in the Armada XP functional spec says: "Interrupt sources ID0–ID28 are private events per CPU. Thus, each processor has a different set of events map interrupts ID0–ID28." Odd grammar aside, that would seem to imply that <&mpic 3> is a per-cpu interrupt itself, thus AFAICS so long as it's cascaded to a GIC PPI and not an SPI then there's no issue there. Robin.
Hello, I'm jumping into the discussion, but I clearly don't have all the context of the discussion. On Thu, 8 Nov 2018 15:54:31 +0000, Robin Murphy wrote: > >> This seems like a semantic different between the two representations, or am > >> I missing something here? Specifically, both the introduction of > >> interrupts-extended and also dropping any mention of using a single per-cpu > >> interrupt (the single combined case is no longer support by Linux; not sure > >> if you want to keep it in the binding). > > > > In regards to no support for the single combined interrupt, it looks > > like Marvell Armada SoCs at least (armada-375 is what I'm looking at) > > have only a single interrupt. Though the interrupt gets routed to MPIC > > which then has a GIC PPI. So it isn't supported or happens to work > > still since it is a PPI? > > Well, the description of the MPIC in the Armada XP functional spec says: > > "Interrupt sources ID0–ID28 are private events per CPU. Thus, each > processor has a different set of events map interrupts ID0–ID28." > > Odd grammar aside, that would seem to imply that <&mpic 3> is a per-cpu > interrupt itself, thus AFAICS so long as it's cascaded to a GIC PPI and > not an SPI then there's no issue there. The Armada XP does not have a GIC at all, but only a MPIC as the primary interrupt controller. However the Armada 38x has both a GIC and a MPIC, and indeed the parent interrupts of the MPIC towards the GIC is: interrupts = <GIC_PPI 15 IRQ_TYPE_LEVEL_HIGH>; Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
On Thu, Nov 8, 2018 at 2:49 AM Michal Simek <michal.simek@xilinx.com> wrote: > > Hi Rob, > > On 05. 10. 18 18:58, Rob Herring wrote: > > Convert ARM CPU binding to DT schema format using json-schema. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > Cc: devicetree@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-mediatek@lists.infradead.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/arm/cpus.txt | 490 ----------------- > > .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ > > 2 files changed, 503 insertions(+), 490 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt > > create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml [...] > I have take a look at xilinx part of this and try to build it for arm64 > platforms and I see errors coming from this cpu description. > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > cpu@0:compatible: ['arm,cortex-a53', 'arm,armv8'] is too long > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > cpu@0:compatible: Additional items are not allowed ('arm,armv8' was > unexpected) Thanks for actually giving this a spin! > Based on grep this is used in a lot of places > compatible = "arm,cortex-a53", "arm,armv8"; > > Should this be moved to just simple? > compatible = "arm,cortex-a53"; I'd normally go with the majority which would be to keep it. However, 'arm,armv8' is of questionable value, isn't actually documented, and doesn't exist for any other version of the architecture. So we should kill it IMO. Paging Mark Rutland and other arm folks... Rob
On Fri, Nov 30, 2018 at 12:00:05PM -0600, Rob Herring wrote: > On Thu, Nov 8, 2018 at 2:49 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > > Hi Rob, > > > > On 05. 10. 18 18:58, Rob Herring wrote: > > > Convert ARM CPU binding to DT schema format using json-schema. > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > > Cc: devicetree@vger.kernel.org > > > Cc: linux-arm-kernel@lists.infradead.org > > > Cc: linux-mediatek@lists.infradead.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > .../devicetree/bindings/arm/cpus.txt | 490 ----------------- > > > .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ > > > 2 files changed, 503 insertions(+), 490 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt > > > create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml > > [...] > > > I have take a look at xilinx part of this and try to build it for arm64 > > platforms and I see errors coming from this cpu description. > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > cpu@0:compatible: ['arm,cortex-a53', 'arm,armv8'] is too long > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > cpu@0:compatible: Additional items are not allowed ('arm,armv8' was > > unexpected) > > Thanks for actually giving this a spin! > > > Based on grep this is used in a lot of places > > compatible = "arm,cortex-a53", "arm,armv8"; > > > > Should this be moved to just simple? > > compatible = "arm,cortex-a53"; > > I'd normally go with the majority which would be to keep it. However, > 'arm,armv8' is of questionable value, isn't actually documented, and > doesn't exist for any other version of the architecture. So we should > kill it IMO. I'd prefer to keep it around, since that's what's used to describe the CPUs on the fastmodel iirc. Will
On Mon, Dec 3, 2018 at 6:40 AM Will Deacon <will.deacon@arm.com> wrote: > > On Fri, Nov 30, 2018 at 12:00:05PM -0600, Rob Herring wrote: > > On Thu, Nov 8, 2018 at 2:49 AM Michal Simek <michal.simek@xilinx.com> wrote: > > > > > > Hi Rob, > > > > > > On 05. 10. 18 18:58, Rob Herring wrote: > > > > Convert ARM CPU binding to DT schema format using json-schema. > > > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > > Cc: Matthias Brugger <matthias.bgg@gmail.com> > > > > Cc: devicetree@vger.kernel.org > > > > Cc: linux-arm-kernel@lists.infradead.org > > > > Cc: linux-mediatek@lists.infradead.org > > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > > --- > > > > .../devicetree/bindings/arm/cpus.txt | 490 ----------------- > > > > .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ > > > > 2 files changed, 503 insertions(+), 490 deletions(-) > > > > delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt > > > > create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml > > > > [...] > > > > > I have take a look at xilinx part of this and try to build it for arm64 > > > platforms and I see errors coming from this cpu description. > > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > > cpu@0:compatible: ['arm,cortex-a53', 'arm,armv8'] is too long > > > /root/linux/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dt.yaml: > > > cpu@0:compatible: Additional items are not allowed ('arm,armv8' was > > > unexpected) > > > > Thanks for actually giving this a spin! > > > > > Based on grep this is used in a lot of places > > > compatible = "arm,cortex-a53", "arm,armv8"; > > > > > > Should this be moved to just simple? > > > compatible = "arm,cortex-a53"; > > > > I'd normally go with the majority which would be to keep it. However, > > 'arm,armv8' is of questionable value, isn't actually documented, and > > doesn't exist for any other version of the architecture. So we should > > kill it IMO. > > I'd prefer to keep it around, since that's what's used to describe the CPUs > on the fastmodel iirc. We can and should keep it for that purpose, but do we need it as a fallback? For real cores though, we have mixture of with and without and one of those need to be fixed. Rob
The current DT binding documentation is not ideal as it is just free form text with at most only a loose structure. This makes reviewing bindings a manual process. The bindings are often duplicating information that's already defined elsewhere and missing information one would need to validate a DTS file. The examples in binding documents are not built and a source of lots of typos sometimes found in review and sometimes not. Secondly, there's no verification that DTS files match what the documentation says. While dtc does do some checking (and has gained more recently), it can't do per binding checks as it would have to understand thousands of compatible strings to match on. There's been a number of proposals over the years to address validation. They've all suffered from inventing their own validation language and the effort it would take to fully define and flush out a validation language. Enter json-schema. The language has a defined specification, maps well to DT data, and there are numerous existing tools which can be leveraged. The actual DT schema doc files are stored as YAML using only a JSON compatible subset. YAML is considered more human readable allowing comments for example. This series adds the build support, some documentation, and converts some bindings (mostly ARM board/soc bindings). The tools, core schema, and meta-schema are in a separate repository[1]. This might eventually be integrated with dtc or added to the kernel, but for now I plan to keep it separate. Future plans/ideas: - Validate examples against the schema. Currently, they are just built with dtc. - Support single targets in addition to validating all enabled dtb targets. - Better control of which schemas to use for validation such as core only or specific lists of schemas. This will make for more easily testing new schema and filtering warnings. - Printing out nodes without any specific schema (i.e. missing schema). This series is dependent on the dt/next branch and is available here[2]. The branch also has a doc2yaml script which can help convert binding files. It's not perfect, but works pretty well considering the input is free form text. Rob [1] https://github.com/robherring/yaml-bindings [2] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git yaml-bindings Rob Herring (36): dt-bindings: arm: alpine: Move CPU control related binding to cpu-enable-method/al,alpine-smp dt-bindings: arm: amlogic: Move 'amlogic,meson-gx-ao-secure' binding to its own file dt-bindings: arm: atmel: Move various sys registers out of SoC binding doc dt-bindings: arm: fsl: Move DCFG and SCFG bindings to their own docs dt-bindings: arm: renesas: Move 'renesas,prr' binding to its own doc dt-bindings: arm: zte: Move sysctrl bindings to their own doc kbuild: Add support for DT binding schema checks dt-bindings: Add a writing DT schemas how-to and annotated example dt-bindings: Convert trivial-devices.txt to json-schema dt-bindings: altera: Convert clkmgr binding to json-schema dt-bindings: timer: Convert ARM timer bindings to json-schema dt-bindings: arm: Convert cpu binding to json-schema dt-bindings: arm: Convert PMU binding to json-schema dt-bindings: arm: Convert primecell binding to json-schema dt-bindings: arm: Convert Actions Semi bindings to jsonschema dt-bindings: arm: Convert Alpine board/soc bindings to json-schema dt-bindings: arm: Convert Altera board/soc bindings to json-schema dt-bindings: arm: Convert Amlogic board/soc bindings to json-schema dt-bindings: arm: Convert Atmel board/soc bindings to json-schema dt-bindings: arm: Convert Calxeda board/soc bindings to json-schema dt-bindings: arm: Convert TI davinci board/soc bindings to json-schema dt-bindings: arm: Convert FSL board/soc bindings to json-schema dt-bindings: arm: Convert MediaTek board/soc bindings to json-schema dt-bindings: arm: Convert TI nspire board/soc bindings to json-schema dt-bindings: arm: Convert Oxford Semi board/soc bindings to json-schema dt-bindings: arm: Convert QCom board/soc bindings to json-schema dt-bindings: arm: Convert Realtek board/soc bindings to json-schema dt-bindings: arm: Convert Rockchip board/soc bindings to json-schema dt-bindings: arm: Convert Renesas board/soc bindings to json-schema dt-bindings: arm: Convert CSR SiRF board/soc bindings to json-schema dt-bindings: arm: Convert SPEAr board/soc bindings to json-schema dt-bindings: arm: Convert ST STi board/soc bindings to json-schema dt-bindings: arm: Convert Tegra board/soc bindings to json-schema dt-bindings: arm: Convert VIA board/soc bindings to json-schema dt-bindings: arm: Convert Xilinx board/soc bindings to json-schema dt-bindings: arm: Convert ZTE board/soc bindings to json-schema .gitignore | 1 + Documentation/Makefile | 2 +- Documentation/devicetree/bindings/.gitignore | 2 + Documentation/devicetree/bindings/Makefile | 30 ++ .../devicetree/bindings/arm/actions.txt | 56 -- .../devicetree/bindings/arm/actions.yaml | 34 ++ .../devicetree/bindings/arm/al,alpine.txt | 88 --- .../devicetree/bindings/arm/al,alpine.yaml | 21 + .../devicetree/bindings/arm/altera.txt | 14 - .../devicetree/bindings/arm/altera.yaml | 20 + .../arm/altera/socfpga-clk-manager.txt | 11 - .../arm/altera/socfpga-clk-manager.yaml | 30 ++ .../devicetree/bindings/arm/amlogic.txt | 131 ----- .../devicetree/bindings/arm/amlogic.yaml | 104 ++++ .../amlogic/amlogic,meson-gx-ao-secure.txt | 28 + .../devicetree/bindings/arm/armadeus.txt | 6 - .../devicetree/bindings/arm/atmel-at91.yaml | 132 +++++ .../arm/{atmel-at91.txt => atmel-sysregs.txt} | 73 +-- Documentation/devicetree/bindings/arm/bhf.txt | 6 - .../devicetree/bindings/arm/calxeda.txt | 15 - .../devicetree/bindings/arm/calxeda.yaml | 22 + .../bindings/arm/compulab-boards.txt | 25 - .../arm/cpu-enable-method/al,alpine-smp | 34 +- .../devicetree/bindings/arm/cpus.txt | 490 ----------------- .../devicetree/bindings/arm/cpus.yaml | 503 ++++++++++++++++++ .../devicetree/bindings/arm/davinci.txt | 25 - .../arm/freescale/fsl,layerscape-dcfg.txt | 19 + .../arm/freescale/fsl,layerscape-scfg.txt | 19 + Documentation/devicetree/bindings/arm/fsl.txt | 224 -------- .../devicetree/bindings/arm/fsl.yaml | 166 ++++++ .../devicetree/bindings/arm/i2se.txt | 22 - .../devicetree/bindings/arm/mediatek.txt | 79 --- .../devicetree/bindings/arm/mediatek.yaml | 85 +++ .../devicetree/bindings/arm/nspire.txt | 14 - .../devicetree/bindings/arm/olimex.txt | 10 - .../devicetree/bindings/arm/oxnas.txt | 14 - .../devicetree/bindings/arm/oxnas.yaml | 25 + Documentation/devicetree/bindings/arm/pmu.txt | 70 --- .../devicetree/bindings/arm/pmu.yaml | 96 ++++ .../devicetree/bindings/arm/primecell.txt | 46 -- .../devicetree/bindings/arm/primecell.yaml | 35 ++ .../devicetree/bindings/arm/qcom.txt | 57 -- .../devicetree/bindings/arm/qcom.yaml | 125 +++++ .../devicetree/bindings/arm/realtek.txt | 22 - .../devicetree/bindings/arm/realtek.yaml | 25 + .../devicetree/bindings/arm/renesas,prr.txt | 18 + .../devicetree/bindings/arm/rockchip.txt | 220 -------- .../devicetree/bindings/arm/rockchip.yaml | 242 +++++++++ .../devicetree/bindings/arm/shmobile.txt | 161 ------ .../devicetree/bindings/arm/shmobile.yaml | 205 +++++++ .../devicetree/bindings/arm/sirf.txt | 11 - .../devicetree/bindings/arm/sirf.yaml | 27 + .../devicetree/bindings/arm/spear.txt | 26 - .../devicetree/bindings/arm/spear.yaml | 25 + Documentation/devicetree/bindings/arm/sti.txt | 23 - .../devicetree/bindings/arm/sti.yaml | 23 + .../devicetree/bindings/arm/technologic.txt | 23 - .../devicetree/bindings/arm/tegra.txt | 60 --- .../devicetree/bindings/arm/tegra.yaml | 88 +++ .../devicetree/bindings/arm/ti/nspire.yaml | 24 + .../bindings/arm/ti/ti,davinci.yaml | 26 + .../devicetree/bindings/arm/vt8500.txt | 22 - .../devicetree/bindings/arm/vt8500.yaml | 23 + .../devicetree/bindings/arm/xilinx.txt | 83 --- .../devicetree/bindings/arm/xilinx.yaml | 81 +++ .../bindings/arm/{zte.txt => zte-sysctrl.txt} | 15 +- .../devicetree/bindings/arm/zte.yaml | 26 + .../devicetree/bindings/example-schema.yaml | 155 ++++++ .../bindings/timer/arm,arch_timer.txt | 112 ---- .../bindings/timer/arm,arch_timer.yaml | 103 ++++ .../bindings/timer/arm,arch_timer_mmio.yaml | 120 +++++ .../bindings/timer/arm,global_timer.txt | 27 - .../bindings/timer/arm,global_timer.yaml | 46 ++ .../devicetree/bindings/trivial-devices.txt | 201 ------- .../devicetree/bindings/trivial-devices.yaml | 414 ++++++++++++++ Documentation/devicetree/writing-schema.md | 111 ++++ Makefile | 8 +- scripts/Makefile.lib | 24 +- 78 files changed, 3344 insertions(+), 2485 deletions(-) create mode 100644 Documentation/devicetree/bindings/.gitignore create mode 100644 Documentation/devicetree/bindings/Makefile delete mode 100644 Documentation/devicetree/bindings/arm/actions.txt create mode 100644 Documentation/devicetree/bindings/arm/actions.yaml delete mode 100644 Documentation/devicetree/bindings/arm/al,alpine.txt create mode 100644 Documentation/devicetree/bindings/arm/al,alpine.yaml delete mode 100644 Documentation/devicetree/bindings/arm/altera.txt create mode 100644 Documentation/devicetree/bindings/arm/altera.yaml delete mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml delete mode 100644 Documentation/devicetree/bindings/arm/amlogic.txt create mode 100644 Documentation/devicetree/bindings/arm/amlogic.yaml create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt delete mode 100644 Documentation/devicetree/bindings/arm/armadeus.txt create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml rename Documentation/devicetree/bindings/arm/{atmel-at91.txt => atmel-sysregs.txt} (67%) delete mode 100644 Documentation/devicetree/bindings/arm/bhf.txt delete mode 100644 Documentation/devicetree/bindings/arm/calxeda.txt create mode 100644 Documentation/devicetree/bindings/arm/calxeda.yaml delete mode 100644 Documentation/devicetree/bindings/arm/compulab-boards.txt delete mode 100644 Documentation/devicetree/bindings/arm/cpus.txt create mode 100644 Documentation/devicetree/bindings/arm/cpus.yaml delete mode 100644 Documentation/devicetree/bindings/arm/davinci.txt create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt delete mode 100644 Documentation/devicetree/bindings/arm/fsl.txt create mode 100644 Documentation/devicetree/bindings/arm/fsl.yaml delete mode 100644 Documentation/devicetree/bindings/arm/i2se.txt delete mode 100644 Documentation/devicetree/bindings/arm/mediatek.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek.yaml delete mode 100644 Documentation/devicetree/bindings/arm/nspire.txt delete mode 100644 Documentation/devicetree/bindings/arm/olimex.txt delete mode 100644 Documentation/devicetree/bindings/arm/oxnas.txt create mode 100644 Documentation/devicetree/bindings/arm/oxnas.yaml delete mode 100644 Documentation/devicetree/bindings/arm/pmu.txt create mode 100644 Documentation/devicetree/bindings/arm/pmu.yaml delete mode 100644 Documentation/devicetree/bindings/arm/primecell.txt create mode 100644 Documentation/devicetree/bindings/arm/primecell.yaml delete mode 100644 Documentation/devicetree/bindings/arm/qcom.txt create mode 100644 Documentation/devicetree/bindings/arm/qcom.yaml delete mode 100644 Documentation/devicetree/bindings/arm/realtek.txt create mode 100644 Documentation/devicetree/bindings/arm/realtek.yaml create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.txt delete mode 100644 Documentation/devicetree/bindings/arm/rockchip.txt create mode 100644 Documentation/devicetree/bindings/arm/rockchip.yaml delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml delete mode 100644 Documentation/devicetree/bindings/arm/sirf.txt create mode 100644 Documentation/devicetree/bindings/arm/sirf.yaml delete mode 100644 Documentation/devicetree/bindings/arm/spear.txt create mode 100644 Documentation/devicetree/bindings/arm/spear.yaml delete mode 100644 Documentation/devicetree/bindings/arm/sti.txt create mode 100644 Documentation/devicetree/bindings/arm/sti.yaml delete mode 100644 Documentation/devicetree/bindings/arm/technologic.txt delete mode 100644 Documentation/devicetree/bindings/arm/tegra.txt create mode 100644 Documentation/devicetree/bindings/arm/tegra.yaml create mode 100644 Documentation/devicetree/bindings/arm/ti/nspire.yaml create mode 100644 Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml delete mode 100644 Documentation/devicetree/bindings/arm/vt8500.txt create mode 100644 Documentation/devicetree/bindings/arm/vt8500.yaml delete mode 100644 Documentation/devicetree/bindings/arm/xilinx.txt create mode 100644 Documentation/devicetree/bindings/arm/xilinx.yaml rename Documentation/devicetree/bindings/arm/{zte.txt => zte-sysctrl.txt} (62%) create mode 100644 Documentation/devicetree/bindings/arm/zte.yaml create mode 100644 Documentation/devicetree/bindings/example-schema.yaml delete mode 100644 Documentation/devicetree/bindings/timer/arm,arch_timer.txt create mode 100644 Documentation/devicetree/bindings/timer/arm,arch_timer.yaml create mode 100644 Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml delete mode 100644 Documentation/devicetree/bindings/timer/arm,global_timer.txt create mode 100644 Documentation/devicetree/bindings/timer/arm,global_timer.yaml delete mode 100644 Documentation/devicetree/bindings/trivial-devices.txt create mode 100644 Documentation/devicetree/bindings/trivial-devices.yaml create mode 100644 Documentation/devicetree/writing-schema.md -- 2.17.1