mbox series

[00/36] Devicetree schema

Message ID 20181005165848.3474-1-robh@kernel.org
Headers show
Series Devicetree schema | expand

Message

Rob Herring (Arm) Oct. 5, 2018, 4:58 p.m. UTC
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

Comments

Alexandre Belloni Oct. 5, 2018, 6:07 p.m. UTC | #1
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
Rob Herring (Arm) Oct. 5, 2018, 6:32 p.m. UTC | #2
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
Marcel Ziswiler Oct. 5, 2018, 10:19 p.m. UTC | #3
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
Rob Herring (Arm) Oct. 5, 2018, 11:36 p.m. UTC | #4
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
Andreas Färber Oct. 6, 2018, 10:54 a.m. UTC | #5
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)
Rob Herring (Arm) Oct. 7, 2018, 7:20 p.m. UTC | #6
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
Shawn Guo Oct. 8, 2018, 6:25 a.m. UTC | #7
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>
Shawn Guo Oct. 8, 2018, 6:30 a.m. UTC | #8
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>
Shawn Guo Oct. 8, 2018, 7:01 a.m. UTC | #9
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

>
Geert Uytterhoeven Oct. 8, 2018, 7:05 a.m. UTC | #10
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
Shawn Guo Oct. 8, 2018, 7:16 a.m. UTC | #11
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>
Geert Uytterhoeven Oct. 8, 2018, 7:47 a.m. UTC | #12
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
Simon Horman Oct. 8, 2018, 8:02 a.m. UTC | #13
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

>
Rob Herring (Arm) Oct. 8, 2018, 1:30 p.m. UTC | #14
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
Rob Herring (Arm) Oct. 8, 2018, 2:57 p.m. UTC | #15
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
Geert Uytterhoeven Oct. 8, 2018, 3:12 p.m. UTC | #16
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
Rob Herring (Arm) Oct. 8, 2018, 4:54 p.m. UTC | #17
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
Will Deacon Oct. 9, 2018, 11:57 a.m. UTC | #18
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
Rob Herring (Arm) Oct. 9, 2018, 6:14 p.m. UTC | #19
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
Patrice CHOTARD Oct. 10, 2018, 9:19 a.m. UTC | #20
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

> +...

>
Will Deacon Oct. 10, 2018, 4:50 p.m. UTC | #21
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
Rob Herring (Arm) Oct. 10, 2018, 6:51 p.m. UTC | #22
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
Will Deacon Oct. 19, 2018, 10:34 a.m. UTC | #23
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
Rob Herring (Arm) Nov. 1, 2018, 7:32 p.m. UTC | #24
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
Michal Simek Nov. 8, 2018, 1:34 p.m. UTC | #25
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
Robin Murphy Nov. 8, 2018, 3:54 p.m. UTC | #26
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.
Thomas Petazzoni Nov. 8, 2018, 3:59 p.m. UTC | #27
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
Rob Herring (Arm) Nov. 30, 2018, 6 p.m. UTC | #28
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
Will Deacon Dec. 3, 2018, 12:40 p.m. UTC | #29
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
Rob Herring (Arm) Dec. 3, 2018, 2:24 p.m. UTC | #30
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