| Message ID | 20181203213223.16986-1-robh@kernel.org |
|---|---|
| Headers | show |
| Series | Devicetree schema | expand |
On 03-12-18, 15:32, Rob Herring wrote: > Convert SPEAr SoC bindings to DT schema format using json-schema. > > Cc: Viresh Kumar <vireshk@kernel.org> > Cc: Shiraz Hashim <shiraz.linux.kernel@gmail.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/spear.txt | 26 ------------------- > .../devicetree/bindings/arm/spear.yaml | 25 ++++++++++++++++++ > 2 files changed, 25 insertions(+), 26 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/spear.txt > create mode 100644 Documentation/devicetree/bindings/arm/spear.yaml Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Hi Rob, On Mon, Dec 03, 2018 at 03:32:00PM -0600, Rob Herring wrote: > diff --git a/Documentation/devicetree/bindings/arm/al,alpine.yaml b/Documentation/devicetree/bindings/arm/al,alpine.yaml > new file mode 100644 > index 000000000000..82e2fafdfece > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/al,alpine.yaml > @@ -0,0 +1,21 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/al,alpine.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Annapurna Labs Alpine Platform Device Tree Bindings > + > +maintainers: > + - Tsahee Zidenberg <tsahee@annapurnalabs.com> Could you add '- Antoine Tenart <antoine.tenart@bootlin.com>' here? Thanks! Antoine > +description: test > + > +properties: > + compatible: > + items: > + - const: al,alpine > + model: > + items: > + - const: "Annapurna Labs Alpine Dev Board" > + > +... > -- > 2.19.1 >
Hi Rob On 12/3/18 10:32 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..47f9b8eebaa0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/sti.yaml > @@ -0,0 +1,23 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/sti.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: ST STi Platforms Device Tree Bindings > + > +maintainers: > + - Patrice Chotard <patrice.chotard@st.com> > + > +properties: > + $nodename: > + const: '/' > + compatible: > + items: > + - enum: > + - st,stih415 > + - st,stih416 > + - st,stih407 > + - st,stih410 > + - st,stih418 > +... > Acked-by: Patrice Chotard <patrice.chotard@st.com> Thanks
On 03/12/2018 at 22:32, Rob Herring wrote: > Convert Atmel SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Nicolas Ferre <nicolas.ferre@microchip.com> I'm listed here... > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Proper email address here... > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/atmel-at91.txt | 72 ---------- > .../devicetree/bindings/arm/atmel-at91.yaml | 133 ++++++++++++++++++ > 2 files changed, 133 insertions(+), 72 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.txt > create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml > > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt > deleted file mode 100644 > index 4bf1b4da7659..000000000000 > --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt > +++ /dev/null > @@ -1,72 +0,0 @@ > -Atmel AT91 device tree bindings. > -================================ [..] > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > new file mode 100644 > index 000000000000..19431f58b906 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > @@ -0,0 +1,133 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/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> > + - Ludovic Desroches <ludovic.desroches@atmel.com> ... and sorry but it's not correct just above ^^^ - wrong Ludovic's email address - wrong Alexander's email address - and I'm not part of the game anymore... So actually our MAINTAINER's entry is up-to-date: please use 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 > + - const: atmel,sama5d31 > + - const: atmel,sama5d3 > + - const: atmel,sama5 > + > + - description: TSE-850 v3 board > + items: > + - const: axentia,tse850v3 > + - const: axentia,linea > + - const: atmel,sama5d31 > + - const: atmel,sama5d3 > + - const: atmel,sama5 > + > + - items: > + - const: axentia,linea > + - const: atmel,sama5d31 > + - const: atmel,sama5d3 > + - const: atmel,sama5 > + > + - items: > + - enum: > + - atmel,sama5d31 > + - atmel,sama5d33 > + - atmel,sama5d34 > + - atmel,sama5d35 > + - atmel,sama5d36 > + - const: atmel,sama5d3 > + - const: atmel,sama5 > + > + - items: > + - enum: > + - atmel,sama5d41 > + - atmel,sama5d42 > + - atmel,sama5d43 > + - atmel,sama5d44 > + - const: atmel,sama5d4 > + - const: atmel,sama5 > + > + - items: > + - enum: > + - atmel,sams70j19 > + - atmel,sams70j20 > + - atmel,sams70j21 > + - atmel,sams70n19 > + - atmel,sams70n20 > + - atmel,sams70n21 > + - atmel,sams70q19 > + - atmel,sams70q20 > + - atmel,sams70q21 > + - const: atmel,sams70 > + - const: atmel,samv7 > + > + - items: > + - enum: > + - atmel,samv70j19 > + - atmel,samv70j20 > + - atmel,samv70n19 > + - atmel,samv70n20 > + - atmel,samv70q19 > + - atmel,samv70q20 > + - const: atmel,samv70 > + - const: atmel,samv7 > + > + - items: > + - enum: > + - atmel,samv71j19 > + - atmel,samv71j20 > + - atmel,samv71j21 > + - atmel,samv71n19 > + - atmel,samv71n20 > + - atmel,samv71n21 > + - atmel,samv71q19 > + - atmel,samv71q20 > + - atmel,samv71q21 > + - const: atmel,samv71 > + - const: atmel,samv7 > + > +... >
On 03/12/2018 22:32, Rob Herring wrote: > It is best practice to have 1 binding per file, so board level bindings > should be separate for various misc SoC bindings. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Carlo Caione <carlo@caione.org> > Cc: Kevin Hilman <khilman@baylibre.com> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-amlogic@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/amlogic.txt | 29 ------------------- > .../amlogic/amlogic,meson-gx-ao-secure.txt | 28 ++++++++++++++++++ > 2 files changed, 28 insertions(+), 29 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt > > diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt > index 4498292b833d..f5c8d50a3506 100644 > --- a/Documentation/devicetree/bindings/arm/amlogic.txt > +++ b/Documentation/devicetree/bindings/arm/amlogic.txt > @@ -107,32 +107,3 @@ Board compatible values (alphabetically, grouped by SoC): > - "amlogic,s400" (Meson axg a113d) > > - "amlogic,u200" (Meson g12a s905d2) > - > -Amlogic Meson Firmware registers Interface > ------------------------------------------- > - > -The Meson SoCs have a register bank with status and data shared with the > -secure firmware. > - > -Required properties: > - - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon" > - > -Properties should indentify components of this register interface : > - > -Meson GX SoC Information > ------------------------- > -A firmware register encodes the SoC type, package and revision information on > -the Meson GX SoCs. > -If present, the following property should be added : > - > -Optional properties: > - - amlogic,has-chip-id: If present, the interface gives the current SoC version. > - > -Example > -------- > - > -ao-secure@140 { > - compatible = "amlogic,meson-gx-ao-secure", "syscon"; > - reg = <0x0 0x140 0x0 0x140>; > - amlogic,has-chip-id; > -}; > diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt > new file mode 100644 > index 000000000000..c67d9f48fb91 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt > @@ -0,0 +1,28 @@ > +Amlogic Meson Firmware registers Interface > +------------------------------------------ > + > +The Meson SoCs have a register bank with status and data shared with the > +secure firmware. > + > +Required properties: > + - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon" > + > +Properties should indentify components of this register interface : > + > +Meson GX SoC Information > +------------------------ > +A firmware register encodes the SoC type, package and revision information on > +the Meson GX SoCs. > +If present, the following property should be added : > + > +Optional properties: > + - amlogic,has-chip-id: If present, the interface gives the current SoC version. > + > +Example > +------- > + > +ao-secure@140 { > + compatible = "amlogic,meson-gx-ao-secure", "syscon"; > + reg = <0x0 0x140 0x0 0x140>; > + amlogic,has-chip-id; > +}; > Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Hi Rob, You forgot linux-amlogic in CC... On 03/12/2018 22:32, Rob Herring wrote: > Convert Amlogic SoC bindings to DT schema format using json-schema. > > Cc: Carlo Caione <carlo@caione.org> > Cc: Kevin Hilman <khilman@baylibre.com> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/amlogic.txt | 109 ------------------ > .../devicetree/bindings/arm/amlogic.yaml | 109 ++++++++++++++++++ > 2 files changed, 109 insertions(+), 109 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/amlogic.txt > create mode 100644 Documentation/devicetree/bindings/arm/amlogic.yaml > > diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt > deleted file mode 100644 > index f5c8d50a3506..000000000000 > --- a/Documentation/devicetree/bindings/arm/amlogic.txt > +++ /dev/null > @@ -1,109 +0,0 @@ > -Amlogic MesonX device tree bindings > -------------------------------------------- > - > -Work in progress statement: > - > -Device tree files and bindings applying to Amlogic SoCs and boards are > -considered "unstable". Any Amlogic device tree binding may change at > -any time. Be sure to use a device tree binary and a kernel image > -generated from the same source tree. > - > -Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a > -stable binding/ABI. > - > ---------------------------------------------------------------- > - > -Boards with the Amlogic Meson6 SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,meson6" > - > -Boards with the Amlogic Meson8 SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,meson8"; > - > -Boards with the Amlogic Meson8b SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,meson8b"; > - > -Boards with the Amlogic Meson8m2 SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,meson8m2"; > - > -Boards with the Amlogic Meson GXBaby SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,meson-gxbb"; > - > -Boards with the Amlogic Meson GXL S905X SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,s905x", "amlogic,meson-gxl"; > - > -Boards with the Amlogic Meson GXL S905D SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,s905d", "amlogic,meson-gxl"; > - > -Boards with the Amlogic Meson GXL S805X SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,s805x", "amlogic,meson-gxl"; > - > -Boards with the Amlogic Meson GXL S905W SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,s905w", "amlogic,meson-gxl"; > - > -Boards with the Amlogic Meson GXM S912 SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,s912", "amlogic,meson-gxm"; > - > -Boards with the Amlogic Meson AXG A113D SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,a113d", "amlogic,meson-axg"; > - > -Boards with the Amlogic Meson G12A S905D2 SoC shall have the following properties: > - Required root node property: > - compatible: "amlogic,g12a"; > - > -Board compatible values (alphabetically, grouped by SoC): > - > - - "geniatech,atv1200" (Meson6) > - > - - "minix,neo-x8" (Meson8) > - > - - "endless,ec100" (Meson8b) > - - "hardkernel,odroid-c1" (Meson8b) > - - "tronfy,mxq" (Meson8b) > - > - - "tronsmart,mxiii-plus" (Meson8m2) > - > - - "amlogic,p200" (Meson gxbb) > - - "amlogic,p201" (Meson gxbb) > - - "friendlyarm,nanopi-k2" (Meson gxbb) > - - "hardkernel,odroid-c2" (Meson gxbb) > - - "nexbox,a95x" (Meson gxbb or Meson gxl s905x) > - - "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb) > - - "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb) > - - "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb) > - - "wetek,hub" (Meson gxbb) > - - "wetek,play2" (Meson gxbb) > - > - - "amlogic,p212" (Meson gxl s905x) > - - "hwacom,amazetv" (Meson gxl s905x) > - - "khadas,vim" (Meson gxl s905x) > - - "libretech,cc" (Meson gxl s905x) > - > - - "amlogic,p230" (Meson gxl s905d) > - - "amlogic,p231" (Meson gxl s905d) > - > - - "amlogic,p241" (Meson gxl s805x) > - > - - "amlogic,p281" (Meson gxl s905w) > - - "oranth,tx3-mini" (Meson gxl s905w) > - > - - "amlogic,q200" (Meson gxm s912) > - - "amlogic,q201" (Meson gxm s912) > - - "khadas,vim2" (Meson gxm s912) > - - "kingnovel,r-box-pro" (Meson gxm S912) > - - "nexbox,a1" (Meson gxm s912) > - - "tronsmart,vega-s96" (Meson gxm s912) > - > - - "amlogic,s400" (Meson axg a113d) > - > - - "amlogic,u200" (Meson g12a s905d2) > diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml > new file mode 100644 > index 000000000000..8b4b11194658 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml > @@ -0,0 +1,109 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/amlogic.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Amlogic MesonX device tree bindings > + > +maintainers: > + - Neil Armstrong <narmstrong@baylibre.com> The maintainer is Kevin Hilman. > + - Carlo Caione <carlo@caione.org> > +description: |+ > + Work in progress statement: > + > + Device tree files and bindings applying to Amlogic SoCs and boards are > + considered "unstable". Any Amlogic device tree binding may change at > + any time. Be sure to use a device tree binary and a kernel image > + generated from the same source tree. > + > + Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a > + stable binding/ABI. > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - enum: > + - geniatech,atv1200 > + - const: amlogic,meson6 > + - items: > + - enum: > + - minix,neo-x8 > + - const: amlogic,meson8 > + - items: > + - enum: > + - tronsmart,mxiii-plus > + - const: amlogic,meson8m2 > + - items: > + - enum: > + - endless,ec100 > + - hardkernel,odroid-c1 > + - tronfy,mxq > + - const: amlogic,meson8b > + - items: > + - enum: > + - amlogic,p200 > + - amlogic,p201 > + - friendlyarm,nanopi-k2 > + - hardkernel,odroid-c2 > + - nexbox,a95x > + - wetek,hub > + - wetek,play2 > + - const: amlogic,meson-gxbb > + - items: > + - enum: > + - tronsmart,vega-s95-pro > + - tronsmart,vega-s95-meta > + - tronsmart,vega-s95-telos > + - const: tronsmart,vega-s95 > + - const: amlogic,meson-gxbb > + - items: > + - enum: > + - amlogic,p241 > + - const: amlogic,s805x > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,p281 > + - oranth,tx3-mini > + - const: amlogic,s905w > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,p212 > + - hwacom,amazetv > + - khadas,vim > + - libretech,cc > + - nexbox,a95x > + - const: amlogic,s905x > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,p230 > + - amlogic,p231 > + - const: amlogic,s905d > + - const: amlogic,meson-gxl > + - items: > + - enum: > + - amlogic,q200 > + - amlogic,q201 > + - khadas,vim2 > + - kingnovel,r-box-pro > + - nexbox,a1 > + - tronsmart,vega-s96 > + - const: amlogic,s912 > + - const: amlogic,meson-gxm > + - items: > + - enum: > + - amlogic,s400 > + - const: amlogic,a113d > + - const: amlogic,meson-axg > + - items: > + - enum: > + - amlogic,u200 > + - const: amlogic,g12a but all this feels wrong for me. First of all, this yaml description is not human friendly and not intuitive at all, and secondly with this conversion we loose all the comments about the SoC family relationship with the compatible strings ! I really understand the point to have automated verification, but really it's a pain to read (I can't imagine newcomers... the actual DT bindings are already hard to read...) and I feel it will be a real pain to write ! Can't we mix an "humam text" with a "yaml" part on a same document ? we are in 2018 (nearly 2019), and it should be easy to extract a yaml description from a text document without pain and keep all the human description, no ? What will be the case for all the bindings with ASCII art to describe the architecture of the HW ? will you simply drop it to replace it with cold yaml description ? Neil > + > +... >
On 03/12/2018 22:32, Rob Herring wrote: > Convert Oxford Semi SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Neil Armstrong <narmstrong@baylibre.com> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-oxnas@groups.io > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/oxnas.txt | 14 ----------- > .../devicetree/bindings/arm/oxnas.yaml | 25 +++++++++++++++++++ > 2 files changed, 25 insertions(+), 14 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/oxnas.txt > create mode 100644 Documentation/devicetree/bindings/arm/oxnas.yaml > > diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt > deleted file mode 100644 > index ac64e60f99f1..000000000000 > --- a/Documentation/devicetree/bindings/arm/oxnas.txt > +++ /dev/null > @@ -1,14 +0,0 @@ > -Oxford Semiconductor OXNAS SoCs Family device tree bindings > -------------------------------------------- > - > -Boards with the OX810SE SoC shall have the following properties: > - Required root node property: > - compatible: "oxsemi,ox810se" > - > -Boards with the OX820 SoC shall have the following properties: > - Required root node property: > - compatible: "oxsemi,ox820" > - > -Board compatible values: > - - "wd,mbwe" (OX810SE) > - - "cloudengines,pogoplugv3" (OX820) > diff --git a/Documentation/devicetree/bindings/arm/oxnas.yaml b/Documentation/devicetree/bindings/arm/oxnas.yaml > new file mode 100644 > index 000000000000..6ae51ef513be > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/oxnas.yaml > @@ -0,0 +1,25 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/oxnas.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Oxford Semiconductor OXNAS SoCs Family device tree bindings > + > +maintainers: > + - Neil Armstrong <narmstrong@baylibre.com> > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - enum: > + - wd,mbwe > + - const: oxsemi,ox810se > + > + - items: > + - enum: > + - cloudengines,pogoplugv3 > + - const: oxsemi,ox820 > We also loose all the "human friendly" description of board/SoC relationship here, and I think it's a shame. Neil
On Mon, Dec 03, 2018 at 03:32:19PM -0600, 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 | 65 ----------- > .../devicetree/bindings/arm/tegra.yaml | 101 ++++++++++++++++++ > 2 files changed, 101 insertions(+), 65 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 c59b15f64346..000000000000 > --- a/Documentation/devicetree/bindings/arm/tegra.txt > +++ /dev/null > @@ -1,65 +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_t30-v1.1 > - toradex,apalis_t30-v1.1-eval > - toradex,apalis-tk1 > - toradex,apalis-tk1-eval > - toradex,apalis-tk1-v1.2 > - toradex,apalis-tk1-v1.2-eval > - toradex,colibri_t20 > - toradex,colibri_t20-eval-v3 > - toradex,colibri_t20-iris > - toradex,colibri_t30 > - toradex,colibri_t30-eval-v3 > - > -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..66493892ffc1 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml > @@ -0,0 +1,101 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/tegra.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# Could you explain what these are? They give 404, so I assume they are more like placeholders and not actually used? > + > +title: NVIDIA Tegra device tree bindings > + > +maintainers: > + - Marcel Ziswiler <marcel.ziswiler@toradex.com> > + - Peter De Schrijver <pdeschrijver@nvidia.com> Not sure how you got that list, but probably from git history. I think it makes sense to replace Marcel and Peter with Jon and myself. Other than that, looks fine to me. Some of the enumerations below look somewhat hard to parse, but I suspect that it will become second nature in no time. Acked-by: Thierry Reding <treding@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: > + - enum: > + - toradex,colibri_t20-eval-v3 > + - toradex,colibri_t20-iris > + - const: toradex,colibri_t20 > + - 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: > + - const: toradex,apalis_t30-eval > + - const: toradex,apalis_t30 > + - const: nvidia,tegra30 > + - items: > + - const: toradex,apalis_t30-eval-v1.1 > + - const: toradex,apalis_t30-eval > + - const: toradex,apalis_t30-v1.1 > + - 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: > + - const: toradex,apalis-tk1-v1.2-eval > + - const: toradex,apalis-tk1-eval > + - const: toradex,apalis-tk1-v1.2 > + - 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 > -- > 2.19.1 >
On Tue, Dec 4, 2018 at 2:43 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > On 03/12/2018 22:32, Rob Herring wrote: > > Convert Oxford Semi SoC bindings to DT schema format using json-schema. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Neil Armstrong <narmstrong@baylibre.com> > > Cc: devicetree@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-oxnas@groups.io > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/arm/oxnas.txt | 14 ----------- > > .../devicetree/bindings/arm/oxnas.yaml | 25 +++++++++++++++++++ > > 2 files changed, 25 insertions(+), 14 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/oxnas.txt > > create mode 100644 Documentation/devicetree/bindings/arm/oxnas.yaml > > > > diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt > > deleted file mode 100644 > > index ac64e60f99f1..000000000000 > > --- a/Documentation/devicetree/bindings/arm/oxnas.txt > > +++ /dev/null > > @@ -1,14 +0,0 @@ > > -Oxford Semiconductor OXNAS SoCs Family device tree bindings > > -------------------------------------------- > > - > > -Boards with the OX810SE SoC shall have the following properties: > > - Required root node property: > > - compatible: "oxsemi,ox810se" > > - > > -Boards with the OX820 SoC shall have the following properties: > > - Required root node property: > > - compatible: "oxsemi,ox820" > > - > > -Board compatible values: > > - - "wd,mbwe" (OX810SE) > > - - "cloudengines,pogoplugv3" (OX820) > > diff --git a/Documentation/devicetree/bindings/arm/oxnas.yaml b/Documentation/devicetree/bindings/arm/oxnas.yaml > > new file mode 100644 > > index 000000000000..6ae51ef513be > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/oxnas.yaml > > @@ -0,0 +1,25 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/arm/oxnas.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Oxford Semiconductor OXNAS SoCs Family device tree bindings > > + > > +maintainers: > > + - Neil Armstrong <narmstrong@baylibre.com> > > + > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - items: > > + - enum: > > + - wd,mbwe > > + - const: oxsemi,ox810se > > + > > + - items: > > + - enum: > > + - cloudengines,pogoplugv3 > > + - const: oxsemi,ox820 > > > > We also loose all the "human friendly" description of board/SoC relationship here, > and I think it's a shame. You can have whatever comments or description properties you like, so how would you like it to look? Rob
Am Montag, 3. Dezember 2018, 22:32:13 CET schrieb Rob Herring: > Convert Rockchip SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Heiko Stuebner <heiko@sntech.de> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-rockchip@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml > new file mode 100644 > index 000000000000..3d30ec9adcd3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > @@ -0,0 +1,251 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/rockchip.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Rockchip platforms device tree bindings > + > +maintainers: > + - Beniamino Galvani <b.galvani@gmail.com> # scripts/get_maintainer.pl -f Documentation/devicetree/bindings/arm/rockchip.txt doesn't list Beniamino at all and he hasn't been active on Rockchip stuff for a number of years, so I'm not really sure where this mention as maintainer comes from. > + - Heiko Stuebner <heiko@sntech.de> > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + - items: > + - enum: > + - amarula,vyasa-rk3288 > + - asus,rk3288-tinker > + - asus,rk3288-tinker-s > + - radxa,rock2-square > + - chipspark,popmetal-rk3288 > + - netxeon,r89 > + - firefly,firefly-rk3288 > + - firefly,firefly-rk3288-beta > + - firefly,firefly-rk3288-reload > + - mqmaker,miqi > + - rockchip,rk3288-fennec > + - const: rockchip,rk3288 [...] > + - items: > + - enum: > + - firefly,firefly-rk3399 > + - firefly,roc-rk3399-pc > + - pine64,rockpro64 > + - rockchip,rk3399-evb > + - rockchip,rk3399-sapphire > + - rockchip,rk3399-sapphire-excavator > + - tsd,rk3399-q7-haikou > + - vamrs,ficus > + - vamrs,rock960 # 96boards RK3399 Rock960 (ROCK960 Consumer Edition) > + - const: rockchip,rk3399 as said before, loosing the description of the boards that get thrown into one listing really decreases the usability a lot. Best example is maybe the rk3399 rock960, where the consumer-edition board is actually named "ficus" and the description actually brings the connection to the product-name. So here it may increase the machine-readability but definitly descreases the human readability of the file itself. I guess just using the format that all the Google-boards got for all boards would just be easiest, so for example the rock960 also would just become: - description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition) items: - const: vamrs,ficus - const: rockchip,rk3399 - description: 96boards RK3399 Ficus (ROCK960 Consumer Edition) items: - const: vamrs,rock960 - const: rockchip,rk3399 Looking at other socs, this is likely similar there. Like on Mediatek all the MT67xx eval boards loose the mapping to the socs marketing name "Helio Foobar" when the description is gone, which could've been helpful for people reading the binding. Heiko > + - description: Google Bob (Asus Chromebook Flip C101PA) > + items: > + - const: google,bob-rev13 > + - const: google,bob-rev12 > + - const: google,bob-rev11 > + - const: google,bob-rev10 > + - const: google,bob-rev9 > + - const: google,bob-rev8 > + - const: google,bob-rev7 > + - const: google,bob-rev6 > + - const: google,bob-rev5 > + - const: google,bob-rev4 > + - const: google,bob > + - const: google,gru > + - const: rockchip,rk3399
On Mon, Dec 03, 2018 at 03:32:14PM -0600, 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: 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> > --- > .../devicetree/bindings/arm/renesas,prr.txt | 20 +++++++++++++++++++ > .../devicetree/bindings/arm/shmobile.txt | 18 ----------------- > 2 files changed, 20 insertions(+), 18 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/renesas,prr.txt Applied for v4.21, but should we add renesas,prr.txt to MAINTAINERS as a follow-up?
On Tue, Dec 4, 2018 at 2:39 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > Hi Rob, > > You forgot linux-amlogic in CC... > > On 03/12/2018 22:32, Rob Herring wrote: > > Convert Amlogic SoC bindings to DT schema format using json-schema. > > > > Cc: Carlo Caione <carlo@caione.org> > > Cc: Kevin Hilman <khilman@baylibre.com> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: devicetree@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- [...] > > + - items: > > + - enum: > > + - amlogic,s400 > > + - const: amlogic,a113d > > + - const: amlogic,meson-axg > > + - items: > > + - enum: > > + - amlogic,u200 > > + - const: amlogic,g12a > > but all this feels wrong for me. > > First of all, this yaml description is not human friendly and not intuitive at all, > and secondly with this conversion we loose all the comments about the SoC family relationship > with the compatible strings ! > > I really understand the point to have automated verification, but really it's a pain to read > (I can't imagine newcomers... the actual DT bindings are already hard to read...) and > I feel it will be a real pain to write ! What do you suggest that would be easier? Is it the YAML itself or the json-schema vocabulary? For the former, we could use {} and [] to make things more json style. But I imagine it is the latter. There is some learning curve for json-schema and is certainly a concern I have, but there would be a learning curve for anything. Our choices are use some existing schema language or invent one. All the previous efforts (there's been about 5 since 2013) have been inventing one, and they've not gone far. There will be far few resources available to train people with if we do something custom. > Can't we mix an "humam text" with a "yaml" part on a same document ? we are in 2018 (nearly 2019), > and it should be easy to extract a yaml description from a text document without pain and > keep all the human description, no ? Yes. Please go look at the annotated example in patch 2. > What will be the case for all the bindings with ASCII art to describe the architecture of the > HW ? will you simply drop it to replace it with cold yaml description ? No, you can have literal blocks and/or comments with however much description you like. In fact, there's some notion to write the descriptions in sphinx and extract them to generate documentation, but that's a ways off. That's just the extent of what is possible. Rob
On Mon, Dec 03, 2018 at 03:32:15PM -0600, 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> > --- > .../devicetree/bindings/arm/shmobile.txt | 151 ------------ > .../devicetree/bindings/arm/shmobile.yaml | 218 ++++++++++++++++++ > 2 files changed, 218 insertions(+), 151 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml Hi Rob, what is this based on? I get a conflict when applying the .txt change and if I knew the base for this patch it would be rather easy to work out what has changed. Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS?
On Mon, Dec 3, 2018 at 10:35 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> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert
Hi Simon, On Tue, Dec 4, 2018 at 3:48 PM Simon Horman <horms@verge.net.au> wrote: > On Mon, Dec 03, 2018 at 03:32:15PM -0600, 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> > > --- > > .../devicetree/bindings/arm/shmobile.txt | 151 ------------ > > .../devicetree/bindings/arm/shmobile.yaml | 218 ++++++++++++++++++ > > 2 files changed, 218 insertions(+), 151 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml > > Hi Rob, > > what is this based on? I get a conflict when applying the .txt change > and if I knew the base for this patch it would be rather easy to work > out what has changed. > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS? Probably even s/shmobile.yaml/renesas.yaml/, while at it? Gr{oetje,eeting}s, Geert
On Tue, Dec 4, 2018 at 8:16 AM Heiko Stuebner <heiko@sntech.de> wrote: > > Am Montag, 3. Dezember 2018, 22:32:13 CET schrieb Rob Herring: > > Convert Rockchip SoC bindings to DT schema format using json-schema. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Heiko Stuebner <heiko@sntech.de> > > Cc: devicetree@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-rockchip@lists.infradead.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml > > new file mode 100644 > > index 000000000000..3d30ec9adcd3 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > > @@ -0,0 +1,251 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/arm/rockchip.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Rockchip platforms device tree bindings > > + > > +maintainers: > > + - Beniamino Galvani <b.galvani@gmail.com> > > # scripts/get_maintainer.pl -f Documentation/devicetree/bindings/arm/rockchip.txt > > doesn't list Beniamino at all and he hasn't been active on Rockchip stuff > for a number of years, so I'm not really sure where this mention as > maintainer comes from. git history. get_maintainers.pl had too many cases where I ended up as the maintainer. I'll drop him. > > + - Heiko Stuebner <heiko@sntech.de> > > + > > +properties: > > + $nodename: > > + const: '/' > > + compatible: > > + oneOf: > > + - items: > > + - enum: > > + - amarula,vyasa-rk3288 > > + - asus,rk3288-tinker > > + - asus,rk3288-tinker-s > > + - radxa,rock2-square > > + - chipspark,popmetal-rk3288 > > + - netxeon,r89 > > + - firefly,firefly-rk3288 > > + - firefly,firefly-rk3288-beta > > + - firefly,firefly-rk3288-reload > > + - mqmaker,miqi > > + - rockchip,rk3288-fennec > > + - const: rockchip,rk3288 > > [...] > > > + - items: > > + - enum: > > + - firefly,firefly-rk3399 > > + - firefly,roc-rk3399-pc > > + - pine64,rockpro64 > > + - rockchip,rk3399-evb > > + - rockchip,rk3399-sapphire > > + - rockchip,rk3399-sapphire-excavator > > + - tsd,rk3399-q7-haikou > > + - vamrs,ficus > > + - vamrs,rock960 # 96boards RK3399 Rock960 (ROCK960 Consumer Edition) > > + - const: rockchip,rk3399 > > > as said before, loosing the description of the boards that get thrown > into one listing really decreases the usability a lot. Sorry, I thought I addressed these previous comments. > Best example is maybe the rk3399 rock960, where the consumer-edition > board is actually named "ficus" and the description actually brings the > connection to the product-name. > > So here it may increase the machine-readability but definitly descreases > the human readability of the file itself. > > I guess just using the format that all the Google-boards got for all boards > would just be easiest, so for example the rock960 also would just become: > > - description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition) > items: > - const: vamrs,ficus > - const: rockchip,rk3399 > > - description: 96boards RK3399 Ficus (ROCK960 Consumer Edition) > items: > - const: vamrs,rock960 > - const: rockchip,rk3399 Sure, you can do this if you like. I prefer the other way as it is a one line change to add a board. The SoC maintainers can pick whatever they like. You could split into a file per SoC too if you wanted. > Looking at other socs, this is likely similar there. Like on Mediatek > all the MT67xx eval boards loose the mapping to the > socs marketing name "Helio Foobar" when the description is gone, > which could've been helpful for people reading the binding. Generally when we had just 'hello,foobar' with 'Hello Foobar' I dropped the comment as I didn't think it added much. Rob
On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Simon, > > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman <horms@verge.net.au> wrote: > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, 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> > > > --- > > > .../devicetree/bindings/arm/shmobile.txt | 151 ------------ > > > .../devicetree/bindings/arm/shmobile.yaml | 218 ++++++++++++++++++ > > > 2 files changed, 218 insertions(+), 151 deletions(-) > > > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > > > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml > > > > Hi Rob, > > > > what is this based on? I get a conflict when applying the .txt change > > and if I knew the base for this patch it would be rather easy to work > > out what has changed. 4.20-rc2 > > > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS? Yes. Though it was pointed out that get_maintainers.pl can pull emails out of this file. We'd need to get that to work by default though. > Probably even s/shmobile.yaml/renesas.yaml/, while at it? Sure, if that's what you all want. Rob
On Tue, Dec 4, 2018 at 2:12 AM <Nicolas.Ferre@microchip.com> wrote: > > On 03/12/2018 at 22:32, Rob Herring wrote: > > Convert Atmel SoC bindings to DT schema format using json-schema. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Nicolas Ferre <nicolas.ferre@microchip.com> > > I'm listed here... > > > Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> > > Proper email address here... > > > > Cc: devicetree@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/arm/atmel-at91.txt | 72 ---------- > > .../devicetree/bindings/arm/atmel-at91.yaml | 133 ++++++++++++++++++ > > 2 files changed, 133 insertions(+), 72 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.txt > > create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml > > > > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt > > deleted file mode 100644 > > index 4bf1b4da7659..000000000000 > > --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt > > +++ /dev/null > > @@ -1,72 +0,0 @@ > > -Atmel AT91 device tree bindings. > > -================================ > > [..] > > > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > > new file mode 100644 > > index 000000000000..19431f58b906 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > > @@ -0,0 +1,133 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/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> > > + - Ludovic Desroches <ludovic.desroches@atmel.com> > > ... and sorry but it's not correct just above ^^^ > - wrong Ludovic's email address > - wrong Alexander's email address > - and I'm not part of the game anymore... Humm, I think get_maintainers.pl says you are as that's where the Cc list came from. But it could be stale if that changed recently. > > So actually our MAINTAINER's entry is up-to-date: please use it. Sorry, it was generated from git history. Many of cases with get_maintainers.pl was not correct and ended with me being listed. Probably should have made the git history a fallback. Rob
Rob Herring <robh@kernel.org> writes: > It is best practice to have 1 binding per file, so board level bindings > should be separate for various misc SoC bindings. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Carlo Caione <carlo@caione.org> > Cc: Kevin Hilman <khilman@baylibre.com> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-amlogic@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/amlogic.txt | 29 ------------------- > .../amlogic/amlogic,meson-gx-ao-secure.txt | 28 ++++++++++++++++++ > 2 files changed, 28 insertions(+), 29 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt Acked-by: Kevin Hilman <khilman@baylibre.com> But this isn't really related to the schema series is it? If you prefer, I can just queue this one separately via my tree. Kevin
On Tue, Dec 4, 2018 at 7:01 PM Kevin Hilman <khilman@baylibre.com> wrote: > > Rob Herring <robh@kernel.org> writes: > > > It is best practice to have 1 binding per file, so board level bindings > > should be separate for various misc SoC bindings. > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Carlo Caione <carlo@caione.org> > > Cc: Kevin Hilman <khilman@baylibre.com> > > Cc: devicetree@vger.kernel.org > > Cc: linux-arm-kernel@lists.infradead.org > > Cc: linux-amlogic@lists.infradead.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .../devicetree/bindings/arm/amlogic.txt | 29 ------------------- > > .../amlogic/amlogic,meson-gx-ao-secure.txt | 28 ++++++++++++++++++ > > 2 files changed, 28 insertions(+), 29 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt > > Acked-by: Kevin Hilman <khilman@baylibre.com> > > But this isn't really related to the schema series is it? If you > prefer, I can just queue this one separately via my tree. Yes, you can take it. Rob
Hi Rob, On Mon, Dec 03, 2018 at 03:31:57PM -0600, Rob Herring wrote: > Convert ARM PMU binding to DT schema format using json-schema. Just a couple of things below. > diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml > new file mode 100644 > index 000000000000..3ea4abfbf276 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/pmu.yaml > @@ -0,0 +1,91 @@ [...] > +properties: > + compatible: > + oneOf: > + - items: > + - enum: > + - apm,potenza-pmu > + - arm,armv8-pmuv3 > + - arm,cortex-a73-pmu > + - arm,cortex-a72-pmu > + - arm,cortex-a57-pmu > + - arm,cortex-a53-pmu > + - arm,cortex-a35-pmu > + - arm,cortex-a17-pmu > + - arm,cortex-a15-pmu > + - arm,cortex-a12-pmu > + - arm,cortex-a9-pmu > + - arm,cortex-a8-pmu > + - arm,cortex-a7-pmu > + - arm,cortex-a5-pmu > + - arm,arm11mpcore-pmu > + - arm,arm1176-pmu > + - arm,arm1136-pmu > + - brcm,vulcan-pmu > + - cavium,thunder-pmu > + - qcom,scorpion-pmu > + - qcom,scorpion-mp-pmu > + - qcom,krait-pmu > + - items: > + - const: arm,cortex-a7-pmu > + - const: arm,cortex-a15-pmu What do these last two mean? > + > + interrupts: > + # Don't know how many CPUs, so no constraints to specify > + description: 1 per-cpu interrupt (PPI) or 1 interrupt per core. > + > + interrupt-affinity: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: > + When using SPIs, specifies a list of phandles to CPU > + nodes corresponding directly to the affinity of > + the SPIs listed in the interrupts property. > + > + When using a PPI, specifies a list of phandles to CPU > + nodes corresponding to the set of CPUs which have > + a PMU of this type signalling the PPI listed in the > + interrupts property, unless this is already specified > + by the PPI interrupt specifier itself (in which case > + the interrupt-affinity property shouldn't be present). > + > + This property should be present when there is more than > + a single SPI. > + > + qcom,no-pc-write: > + type: boolean > + description: > + Indicates that this PMU doesn't support the 0xc and 0xd events. > + > + secure-reg-access: > + type: boolean > + description: > + Indicates that the ARMv7 Secure Debug Enable Register > + (SDER) is accessible. This will cause the driver to do > + any setup required that is only possible in ARMv7 secure > + state. If not present the ARMv7 SDER will not be touched, > + which means the PMU may fail to operate unless external > + code (bootloader or security monitor) has performed the > + appropriate initialisation. Note that this property is > + not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux > + in Non-secure state. > + > +required: > + - compatible I probably said this before, but I do think that it's a shame to lose the example binding, especially for something like the PMU where you can pretty much take an example and bang in your own IRQ numbers to get it up and running. Will
On 12/3/18 3:31 PM, Rob Herring wrote: > Convert Altera clkmgr to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Dinh Nguyen <dinguyen@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../arm/altera/socfpga-clk-manager.txt | 11 ------- > .../arm/altera/socfpga-clk-manager.yaml | 31 +++++++++++++++++++ > 2 files changed, 31 insertions(+), 11 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt > create mode 100644 Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml > > diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt > deleted file mode 100644 > index 2c28f1d12f45..000000000000 > --- a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt > +++ /dev/null > @@ -1,11 +0,0 @@ > -Altera SOCFPGA Clock Manager > - > -Required properties: > -- compatible : "altr,clk-mgr" > -- reg : Should contain base address and length for Clock Manager > - > -Example: > - clkmgr@ffd04000 { > - compatible = "altr,clk-mgr"; > - reg = <0xffd04000 0x1000>; > - }; > diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml > new file mode 100644 > index 000000000000..e4131fa42b26 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml > @@ -0,0 +1,31 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/altera/socfpga-clk-manager.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Altera SOCFPGA Clock Manager > + > +maintainers: > + - Dinh Nguyen <dinguyen@kernel.org> > + > +description: test > + > +properties: > + compatible: > + items: > + - const: altr,clk-mgr > + reg: > + maxItems: 1 > + > +required: > + - compatible > + > +examples: > + - | > + clkmgr@ffd04000 { > + compatible = "altr,clk-mgr"; > + reg = <0xffd04000 0x1000>; > + }; > + > +... > Acked-by: Dinh Nguyen <dinguyen@kernel.org>
On 12/3/18 3:32 PM, Rob Herring wrote: > Convert Altera SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Dinh Nguyen <dinguyen@kernel.org> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/arm/altera.txt | 14 ------------- > .../devicetree/bindings/arm/altera.yaml | 20 +++++++++++++++++++ > 2 files changed, 20 insertions(+), 14 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/altera.txt > create mode 100644 Documentation/devicetree/bindings/arm/altera.yaml > > diff --git a/Documentation/devicetree/bindings/arm/altera.txt b/Documentation/devicetree/bindings/arm/altera.txt > deleted file mode 100644 > index 558735aacca8..000000000000 > --- a/Documentation/devicetree/bindings/arm/altera.txt > +++ /dev/null > @@ -1,14 +0,0 @@ > -Altera's SoCFPGA platform device tree bindings > ---------------------------------------------- > - > -Boards with Cyclone 5 SoC: > -Required root node properties: > -compatible = "altr,socfpga-cyclone5", "altr,socfpga"; > - > -Boards with Arria 5 SoC: > -Required root node properties: > -compatible = "altr,socfpga-arria5", "altr,socfpga"; > - > -Boards with Arria 10 SoC: > -Required root node properties: > -compatible = "altr,socfpga-arria10", "altr,socfpga"; > diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml > new file mode 100644 > index 000000000000..49e0362ddc11 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/altera.yaml > @@ -0,0 +1,20 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/altera.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Altera's SoCFPGA platform device tree bindings > + > +maintainers: > + - Dinh Nguyen <dinguyen@kernel.org> > + > +properties: > + compatible: > + items: > + - enum: > + - altr,socfpga-cyclone5 > + - altr,socfpga-arria5 > + - altr,socfpga-arria10 > + - const: altr,socfpga > +... > Acked-by: Dinh Nguyen <dinguyen@kernel.org>
On Wed, Dec 5, 2018 at 4:08 AM Will Deacon <will.deacon@arm.com> wrote: > > Hi Rob, > > On Mon, Dec 03, 2018 at 03:31:57PM -0600, Rob Herring wrote: > > Convert ARM PMU binding to DT schema format using json-schema. > > Just a couple of things below. > > > diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml > > new file mode 100644 > > index 000000000000..3ea4abfbf276 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/pmu.yaml > > @@ -0,0 +1,91 @@ > > [...] > > > +properties: > > + compatible: > > + oneOf: > > + - items: > > + - enum: > > + - apm,potenza-pmu > > + - arm,armv8-pmuv3 > > + - arm,cortex-a73-pmu > > + - arm,cortex-a72-pmu > > + - arm,cortex-a57-pmu > > + - arm,cortex-a53-pmu > > + - arm,cortex-a35-pmu > > + - arm,cortex-a17-pmu > > + - arm,cortex-a15-pmu > > + - arm,cortex-a12-pmu > > + - arm,cortex-a9-pmu > > + - arm,cortex-a8-pmu > > + - arm,cortex-a7-pmu > > + - arm,cortex-a5-pmu > > + - arm,arm11mpcore-pmu > > + - arm,arm1176-pmu > > + - arm,arm1136-pmu > > + - brcm,vulcan-pmu > > + - cavium,thunder-pmu > > + - qcom,scorpion-pmu > > + - qcom,scorpion-mp-pmu > > + - qcom,krait-pmu > > + - items: > > + - const: arm,cortex-a7-pmu > > + - const: arm,cortex-a15-pmu > > What do these last two mean? The first list only allows a single compatible string. This list says there are 2 and that the compatible property should be: compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu"; Which shows up here: arch/arm/boot/dts/sun6i-a31.dtsi: compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu"; arch/arm/boot/dts/sun7i-a20.dtsi: compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu"; Maybe the dts is wrong and should be fixed? > > + interrupts: > > + # Don't know how many CPUs, so no constraints to specify > > + description: 1 per-cpu interrupt (PPI) or 1 interrupt per core. > > + > > + interrupt-affinity: > > + $ref: /schemas/types.yaml#/definitions/phandle-array > > + description: > > + When using SPIs, specifies a list of phandles to CPU > > + nodes corresponding directly to the affinity of > > + the SPIs listed in the interrupts property. > > + > > + When using a PPI, specifies a list of phandles to CPU > > + nodes corresponding to the set of CPUs which have > > + a PMU of this type signalling the PPI listed in the > > + interrupts property, unless this is already specified > > + by the PPI interrupt specifier itself (in which case > > + the interrupt-affinity property shouldn't be present). > > + > > + This property should be present when there is more than > > + a single SPI. > > + > > + qcom,no-pc-write: > > + type: boolean > > + description: > > + Indicates that this PMU doesn't support the 0xc and 0xd events. > > + > > + secure-reg-access: > > + type: boolean > > + description: > > + Indicates that the ARMv7 Secure Debug Enable Register > > + (SDER) is accessible. This will cause the driver to do > > + any setup required that is only possible in ARMv7 secure > > + state. If not present the ARMv7 SDER will not be touched, > > + which means the PMU may fail to operate unless external > > + code (bootloader or security monitor) has performed the > > + appropriate initialisation. Note that this property is > > + not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux > > + in Non-secure state. > > + > > +required: > > + - compatible > > I probably said this before, but I do think that it's a shame to lose the > example binding, especially for something like the PMU where you can > pretty much take an example and bang in your own IRQ numbers to get it > up and running. I just thought it is so trivial that it didn't add much. I think most folks would copy-n-paste from an actual dts file which has all the other nodes you just need to update addresses and irq nums. Rob
On Mon, Dec 03, 2018 at 03:32:11PM -0600, Rob Herring wrote: > Convert QCom SoC bindings to DT schema format using json-schema. > > Cc: Andy Gross <andy.gross@linaro.org> > Cc: David Brown <david.brown@linaro.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Andy Gross <andy.gross@linaro.org>
On Mon, Dec 03, 2018 at 03:32:07PM -0600, 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 | 229 ------------------ > .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++++++++++ Rob, I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my tree, so please send it via your tree. Acked-by: Shawn Guo <shawnguo@kernel.org>
On Mon, Dec 03, 2018 at 03:32:23PM -0600, Rob Herring wrote: > Convert ZTE SoC bindings to DT schema format using json-schema. > > Cc: Jun Nie <jun.nie@linaro.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-arm-kernel@lists.infradead.org > Cc: devicetree@vger.kernel.org > Acked-by: Shawn Guo <shawnguo@kernel.org> > Signed-off-by: Rob Herring <robh@kernel.org> > --- > Documentation/devicetree/bindings/arm/zte.txt | 14 ---------- > .../devicetree/bindings/arm/zte.yaml | 26 +++++++++++++++++++ I do not have any changes on bindings/arm/zte.txt in my queue, so please you take it. Shawn
On 04/12/18 3:02 AM, Rob Herring wrote: > Convert TI Davinci SoC bindings to DT schema format using json-schema. > > Cc: Sekhar Nori <nsekhar@ti.com> > Cc: Kevin Hilman <khilman@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: devicetree@vger.kernel.org > Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Sekhar Nori <nsekhar@ti.com> Thanks, Sekhar
On Wed, Dec 05, 2018 at 09:42:04AM -0600, Rob Herring wrote: > On Wed, Dec 5, 2018 at 4:08 AM Will Deacon <will.deacon@arm.com> wrote: > > On Mon, Dec 03, 2018 at 03:31:57PM -0600, Rob Herring wrote: > > > +properties: > > > + compatible: > > > + oneOf: > > > + - items: > > > + - enum: > > > + - apm,potenza-pmu > > > + - arm,armv8-pmuv3 > > > + - arm,cortex-a73-pmu > > > + - arm,cortex-a72-pmu > > > + - arm,cortex-a57-pmu > > > + - arm,cortex-a53-pmu > > > + - arm,cortex-a35-pmu > > > + - arm,cortex-a17-pmu > > > + - arm,cortex-a15-pmu > > > + - arm,cortex-a12-pmu > > > + - arm,cortex-a9-pmu > > > + - arm,cortex-a8-pmu > > > + - arm,cortex-a7-pmu > > > + - arm,cortex-a5-pmu > > > + - arm,arm11mpcore-pmu > > > + - arm,arm1176-pmu > > > + - arm,arm1136-pmu > > > + - brcm,vulcan-pmu > > > + - cavium,thunder-pmu > > > + - qcom,scorpion-pmu > > > + - qcom,scorpion-mp-pmu > > > + - qcom,krait-pmu > > > + - items: > > > + - const: arm,cortex-a7-pmu > > > + - const: arm,cortex-a15-pmu > > > > What do these last two mean? > > The first list only allows a single compatible string. This list says > there are 2 and that the compatible property should be: > compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu"; > > Which shows up here: > arch/arm/boot/dts/sun6i-a31.dtsi: compatible = > "arm,cortex-a7-pmu", "arm,cortex-a15-pmu"; > arch/arm/boot/dts/sun7i-a20.dtsi: compatible = > "arm,cortex-a7-pmu", "arm,cortex-a15-pmu"; > > Maybe the dts is wrong and should be fixed? Yes, that's wrong and you could end up with the kernel exposing the wrong events to userspace. So I think we can fix the .dts and leave the binding without this. > > > +required: > > > + - compatible > > > > I probably said this before, but I do think that it's a shame to lose the > > example binding, especially for something like the PMU where you can > > pretty much take an example and bang in your own IRQ numbers to get it > > up and running. > > I just thought it is so trivial that it didn't add much. I think most > folks would copy-n-paste from an actual dts file which has all the > other nodes you just need to update addresses and irq nums. True... even more of a reason to fix thise sun* .dts files then! Will
On Wed, Dec 5, 2018 at 1:44 PM Simon Horman <horms@verge.net.au> wrote: > > On Tue, Dec 04, 2018 at 09:08:57AM -0600, Rob Herring wrote: > > On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > > Hi Simon, > > > > > > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman <horms@verge.net.au> wrote: > > > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, 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> > > > > > --- > > > > > .../devicetree/bindings/arm/shmobile.txt | 151 ------------ > > > > > .../devicetree/bindings/arm/shmobile.yaml | 218 ++++++++++++++++++ > > > > > 2 files changed, 218 insertions(+), 151 deletions(-) > > > > > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > > > > > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml > > > > > > > > Hi Rob, > > > > > > > > what is this based on? I get a conflict when applying the .txt change > > > > and if I knew the base for this patch it would be rather easy to work > > > > out what has changed. > > > > 4.20-rc2 > > > > > > > > > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS? > > > > Yes. Though it was pointed out that get_maintainers.pl can pull emails > > out of this file. We'd need to get that to work by default though. > > > > > Probably even s/shmobile.yaml/renesas.yaml/, while at it? > > > > Sure, if that's what you all want. > > How about this? LGTM > From: Rob Herring <robh@kernel.org> > Subject: [PATCH v2.1] dt-bindings: arm: Convert Renesas board/soc bindings to > json-schema > > Convert Renesas SoC bindings to DT schema format using json-schema. > > v2.1 [Simon Horman] > - rebased on renesas-devel-20181204-v4.20-rc5 > + Added r8a7744 development platform and SoM > + Correct RZ/G2E part number > - Update MAINTAINERS > > Signed-off-by: Rob Herring <robh@kernel.org> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > --- > Documentation/devicetree/bindings/arm/renesas.yaml | 228 +++++++++++++++++++++ > Documentation/devicetree/bindings/arm/shmobile.txt | 155 -------------- > MAINTAINERS | 4 +- > 3 files changed, 230 insertions(+), 157 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/renesas.yaml > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt
On Tue, Dec 4, 2018 at 8:44 AM Rob Herring <robh@kernel.org> wrote: > > On Tue, Dec 4, 2018 at 2:39 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > > > Hi Rob, > > > > You forgot linux-amlogic in CC... > > > > On 03/12/2018 22:32, Rob Herring wrote: > > > Convert Amlogic SoC bindings to DT schema format using json-schema. > > > > > > Cc: Carlo Caione <carlo@caione.org> > > > Cc: Kevin Hilman <khilman@baylibre.com> > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: devicetree@vger.kernel.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > [...] > > > > + - items: > > > + - enum: > > > + - amlogic,s400 > > > + - const: amlogic,a113d > > > + - const: amlogic,meson-axg > > > + - items: > > > + - enum: > > > + - amlogic,u200 > > > + - const: amlogic,g12a > > > > but all this feels wrong for me. > > > > First of all, this yaml description is not human friendly and not intuitive at all, > > and secondly with this conversion we loose all the comments about the SoC family relationship > > with the compatible strings ! > > > > I really understand the point to have automated verification, but really it's a pain to read > > (I can't imagine newcomers... the actual DT bindings are already hard to read...) and > > I feel it will be a real pain to write ! > > What do you suggest that would be easier? Is it the YAML itself or the > json-schema vocabulary? For the former, we could use {} and [] to make > things more json style. But I imagine it is the latter. > > There is some learning curve for json-schema and is certainly a > concern I have, but there would be a learning curve for anything. Our > choices are use some existing schema language or invent one. All the > previous efforts (there's been about 5 since 2013) have been inventing > one, and they've not gone far. There will be far few resources > available to train people with if we do something custom. > > > Can't we mix an "humam text" with a "yaml" part on a same document ? we are in 2018 (nearly 2019), > > and it should be easy to extract a yaml description from a text document without pain and > > keep all the human description, no ? > > Yes. Please go look at the annotated example in patch 2. How's this?: compatible: oneOf: - description: Boards with the Amlogic Meson6 SoC items: - enum: - geniatech,atv1200 - const: amlogic,meson6 - description: Boards with the Amlogic Meson8 SoC items: - enum: - minix,neo-x8 - const: amlogic,meson8 - description: Boards with the Amlogic Meson8m2 SoC items: - enum: - tronsmart,mxiii-plus - const: amlogic,meson8m2
On Tue, Dec 4, 2018 at 2:50 AM Thierry Reding <thierry.reding@gmail.com> wrote: > > On Mon, Dec 03, 2018 at 03:32:19PM -0600, 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 | 65 ----------- > > .../devicetree/bindings/arm/tegra.yaml | 101 ++++++++++++++++++ > > 2 files changed, 101 insertions(+), 65 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 c59b15f64346..000000000000 > > --- a/Documentation/devicetree/bindings/arm/tegra.txt > > +++ /dev/null > > @@ -1,65 +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_t30-v1.1 > > - toradex,apalis_t30-v1.1-eval > > - toradex,apalis-tk1 > > - toradex,apalis-tk1-eval > > - toradex,apalis-tk1-v1.2 > > - toradex,apalis-tk1-v1.2-eval > > - toradex,colibri_t20 > > - toradex,colibri_t20-eval-v3 > > - toradex,colibri_t20-iris > > - toradex,colibri_t30 > > - toradex,colibri_t30-eval-v3 > > - > > -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..66493892ffc1 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml > > @@ -0,0 +1,101 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/arm/tegra.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > Could you explain what these are? They give 404, so I assume they are > more like placeholders and not actually used? Please read the documentation in patch 2. They are used, but aren't live URLs. > > + > > +title: NVIDIA Tegra device tree bindings > > + > > +maintainers: > > + - Marcel Ziswiler <marcel.ziswiler@toradex.com> > > + - Peter De Schrijver <pdeschrijver@nvidia.com> > > Not sure how you got that list, but probably from git history. I think > it makes sense to replace Marcel and Peter with Jon and myself. Will do. > Other than that, looks fine to me. Some of the enumerations below look > somewhat hard to parse, but I suspect that it will become second nature > in no time. We can add descriptions and/or comments if that helps. I didn't add them if not already there. > Acked-by: Thierry Reding <treding@nvidia.com> Thanks. Rob
On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo <shawnguo@kernel.org> wrote: > > On Mon, Dec 03, 2018 at 03:32:07PM -0600, 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 | 229 ------------------ > > .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++++++++++ > > Rob, > > I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my > tree, so please send it via your tree. What about: c386f362957b dt-bindings: Add compatible string for LS1028A-QDS 3671cd57de06 dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding > > Acked-by: Shawn Guo <shawnguo@kernel.org>
On Thu, Dec 06, 2018 at 04:38:44PM -0600, Rob Herring wrote: > On Tue, Dec 4, 2018 at 2:50 AM Thierry Reding <thierry.reding@gmail.com> wrote: > > > > On Mon, Dec 03, 2018 at 03:32:19PM -0600, 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 | 65 ----------- > > > .../devicetree/bindings/arm/tegra.yaml | 101 ++++++++++++++++++ > > > 2 files changed, 101 insertions(+), 65 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 c59b15f64346..000000000000 > > > --- a/Documentation/devicetree/bindings/arm/tegra.txt > > > +++ /dev/null > > > @@ -1,65 +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_t30-v1.1 > > > - toradex,apalis_t30-v1.1-eval > > > - toradex,apalis-tk1 > > > - toradex,apalis-tk1-eval > > > - toradex,apalis-tk1-v1.2 > > > - toradex,apalis-tk1-v1.2-eval > > > - toradex,colibri_t20 > > > - toradex,colibri_t20-eval-v3 > > > - toradex,colibri_t20-iris > > > - toradex,colibri_t30 > > > - toradex,colibri_t30-eval-v3 > > > - > > > -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..66493892ffc1 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/arm/tegra.yaml > > > @@ -0,0 +1,101 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/arm/tegra.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > Could you explain what these are? They give 404, so I assume they are > > more like placeholders and not actually used? > > Please read the documentation in patch 2. They are used, but aren't live URLs. Okay, thanks for pointing that out. I wasn't Cc'ed on that patch, so it took a while to hunt it down. > > > + > > > +title: NVIDIA Tegra device tree bindings > > > + > > > +maintainers: > > > + - Marcel Ziswiler <marcel.ziswiler@toradex.com> > > > + - Peter De Schrijver <pdeschrijver@nvidia.com> > > > > Not sure how you got that list, but probably from git history. I think > > it makes sense to replace Marcel and Peter with Jon and myself. > > Will do. > > > Other than that, looks fine to me. Some of the enumerations below look > > somewhat hard to parse, but I suspect that it will become second nature > > in no time. > > We can add descriptions and/or comments if that helps. I didn't add > them if not already there. My comment was regarding the schema syntax with the oneOf, - items, etc. That's all new to me and difficult to read, but I'm sure I'll get used to it. Thierry
On Thu, Dec 06, 2018 at 05:33:13PM -0600, Rob Herring wrote: > On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo <shawnguo@kernel.org> wrote: > > > > On Mon, Dec 03, 2018 at 03:32:07PM -0600, 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 | 229 ------------------ > > > .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++++++++++ > > > > Rob, > > > > I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my > > tree, so please send it via your tree. > > What about: > > c386f362957b dt-bindings: Add compatible string for LS1028A-QDS > 3671cd57de06 dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding Ah, sorry, I only checked on imx/dt branch and forgot imx/dt64. I will drop the changes on fsl.txt and update fsl.yaml after it hits mainline. Shawn
Am Sonntag, 9. Dezember 2018, 23:14:05 CET schrieb Heiko Stuebner: Forgot the From: Rob Herring <robh@kernel.org> here, but if you're ok with how it looks I can apply it to my tree. Heiko > Convert Rockchip SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Heiko Stuebner <heiko@sntech.de> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-rockchip@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > [move to per-board entries and added recently added boards] > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > --- > Hi Rob, > > there are boards where the description adds much value and on others > it is maybe less, but personally I'd like to keep things uniform, > as that makes reading these things easier if the format stays the > same all the time, so I've gone forward and just did the conversion > > make dtbs_check did not complain about the schema it seems but I > did end up with an error later on: > > FATAL ERROR: Unknown output format "yaml" > make[2]: *** [scripts/Makefile.lib:313: arch/arm/boot/dts/rk3036-evb.dt.yaml] Fehler 1 > > But I guess I did not mess up the schema yet. > > So does it look ok that way? > Heiko > > .../devicetree/bindings/arm/rockchip.txt | 240 ---------- > .../devicetree/bindings/arm/rockchip.yaml | 419 ++++++++++++++++++ > 2 files changed, 419 insertions(+), 240 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/rockchip.txt > create mode 100644 Documentation/devicetree/bindings/arm/rockchip.yaml > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt > deleted file mode 100644 > index 0cc71236d639..000000000000 > --- a/Documentation/devicetree/bindings/arm/rockchip.txt > +++ /dev/null > @@ -1,240 +0,0 @@ > -Rockchip platforms device tree bindings > ---------------------------------------- > - > -- 96boards RK3399 Ficus (ROCK960 Enterprise Edition) > - Required root node properties: > - - compatible = "vamrs,ficus", "rockchip,rk3399"; > - > -- 96boards RK3399 Rock960 (ROCK960 Consumer Edition) > - Required root node properties: > - - compatible = "vamrs,rock960", "rockchip,rk3399"; > - > -- Amarula Vyasa RK3288 board > - Required root node properties: > - - compatible = "amarula,vyasa-rk3288", "rockchip,rk3288"; > - > -- Asus Tinker board > - Required root node properties: > - - compatible = "asus,rk3288-tinker", "rockchip,rk3288"; > - > -- Asus Tinker board S > - Required root node properties: > - - compatible = "asus,rk3288-tinker-s", "rockchip,rk3288"; > - > -- Kylin RK3036 board: > - Required root node properties: > - - compatible = "rockchip,kylin-rk3036", "rockchip,rk3036"; > - > -- MarsBoard RK3066 board: > - Required root node properties: > - - compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a"; > - > -- bq Curie 2 tablet: > - Required root node properties: > - - compatible = "mundoreader,bq-curie2", "rockchip,rk3066a"; > - > -- ChipSPARK Rayeager PX2 board: > - Required root node properties: > - - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a"; > - > -- Radxa Rock board: > - Required root node properties: > - - compatible = "radxa,rock", "rockchip,rk3188"; > - > -- Radxa Rock2 Square board: > - Required root node properties: > - - compatible = "radxa,rock2-square", "rockchip,rk3288"; > - > -- Rikomagic MK808 v1 board: > - Required root node properties: > - - compatible = "rikomagic,mk808", "rockchip,rk3066a"; > - > -- Firefly Firefly-RK3288 board: > - Required root node properties: > - - compatible = "firefly,firefly-rk3288", "rockchip,rk3288"; > - or > - - compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288"; > - > -- Firefly Firefly-RK3288 Reload board: > - Required root node properties: > - - compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288"; > - > -- Firefly Firefly-RK3399 board: > - Required root node properties: > - - compatible = "firefly,firefly-rk3399", "rockchip,rk3399"; > - > -- Firefly roc-rk3328-cc board: > - Required root node properties: > - - compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328"; > - > -- Firefly ROC-RK3399-PC board: > - Required root node properties: > - - compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399"; > - > -- ChipSPARK PopMetal-RK3288 board: > - Required root node properties: > - - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288"; > - > -- Netxeon R89 board: > - Required root node properties: > - - compatible = "netxeon,r89", "rockchip,rk3288"; > - > -- GeekBuying GeekBox: > - Required root node properties: > - - compatible = "geekbuying,geekbox", "rockchip,rk3368"; > - > -- Google Bob (Asus Chromebook Flip C101PA): > - Required root node properties: > - compatible = "google,bob-rev13", "google,bob-rev12", > - "google,bob-rev11", "google,bob-rev10", > - "google,bob-rev9", "google,bob-rev8", > - "google,bob-rev7", "google,bob-rev6", > - "google,bob-rev5", "google,bob-rev4", > - "google,bob", "google,gru", "rockchip,rk3399"; > - > -- Google Brain (dev-board): > - Required root node properties: > - - compatible = "google,veyron-brain-rev0", "google,veyron-brain", > - "google,veyron", "rockchip,rk3288"; > - > -- Google Gru (dev-board): > - Required root node properties: > - - compatible = "google,gru-rev15", "google,gru-rev14", > - "google,gru-rev13", "google,gru-rev12", > - "google,gru-rev11", "google,gru-rev10", > - "google,gru-rev9", "google,gru-rev8", > - "google,gru-rev7", "google,gru-rev6", > - "google,gru-rev5", "google,gru-rev4", > - "google,gru-rev3", "google,gru-rev2", > - "google,gru", "rockchip,rk3399"; > - > -- Google Jaq (Haier Chromebook 11 and more): > - Required root node properties: > - - compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4", > - "google,veyron-jaq-rev3", "google,veyron-jaq-rev2", > - "google,veyron-jaq-rev1", "google,veyron-jaq", > - "google,veyron", "rockchip,rk3288"; > - > -- Google Jerry (Hisense Chromebook C11 and more): > - Required root node properties: > - - compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6", > - "google,veyron-jerry-rev5", "google,veyron-jerry-rev4", > - "google,veyron-jerry-rev3", "google,veyron-jerry", > - "google,veyron", "rockchip,rk3288"; > - > -- Google Kevin (Samsung Chromebook Plus): > - Required root node properties: > - - compatible = "google,kevin-rev15", "google,kevin-rev14", > - "google,kevin-rev13", "google,kevin-rev12", > - "google,kevin-rev11", "google,kevin-rev10", > - "google,kevin-rev9", "google,kevin-rev8", > - "google,kevin-rev7", "google,kevin-rev6", > - "google,kevin", "google,gru", "rockchip,rk3399"; > - > -- Google Mickey (Asus Chromebit CS10): > - Required root node properties: > - - compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7", > - "google,veyron-mickey-rev6", "google,veyron-mickey-rev5", > - "google,veyron-mickey-rev4", "google,veyron-mickey-rev3", > - "google,veyron-mickey-rev2", "google,veyron-mickey-rev1", > - "google,veyron-mickey-rev0", "google,veyron-mickey", > - "google,veyron", "rockchip,rk3288"; > - > -- Google Minnie (Asus Chromebook Flip C100P): > - Required root node properties: > - - compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3", > - "google,veyron-minnie-rev2", "google,veyron-minnie-rev1", > - "google,veyron-minnie-rev0", "google,veyron-minnie", > - "google,veyron", "rockchip,rk3288"; > - > -- Google Pinky (dev-board): > - Required root node properties: > - - compatible = "google,veyron-pinky-rev2", "google,veyron-pinky", > - "google,veyron", "rockchip,rk3288"; > - > -- Google Speedy (Asus C201 Chromebook): > - Required root node properties: > - - compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8", > - "google,veyron-speedy-rev7", "google,veyron-speedy-rev6", > - "google,veyron-speedy-rev5", "google,veyron-speedy-rev4", > - "google,veyron-speedy-rev3", "google,veyron-speedy-rev2", > - "google,veyron-speedy", "google,veyron", "rockchip,rk3288"; > - > -- mqmaker MiQi: > - Required root node properties: > - - compatible = "mqmaker,miqi", "rockchip,rk3288"; > - > -- Phytec phyCORE-RK3288: Rapid Development Kit > - Required root node properties: > - - compatible = "phytec,rk3288-pcm-947", "phytec,rk3288-phycore-som", "rockchip,rk3288"; > - > -- Pine64 Rock64 board: > - Required root node properties: > - - compatible = "pine64,rock64", "rockchip,rk3328"; > - > -- Pine64 RockPro64 board: > - Required root node properties: > - - compatible = "pine64,rockpro64", "rockchip,rk3399"; > - > -- Rockchip PX3 Evaluation board: > - Required root node properties: > - - compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188"; > - > -- Rockchip PX5 Evaluation board: > - Required root node properties: > - - compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368"; > - > -- Rockchip PX30 Evaluation board: > - Required root node properties: > - - compatible = "rockchip,px30-evb", "rockchip,px30"; > - > -- Rockchip RV1108 Evaluation board > - Required root node properties: > - - compatible = "rockchip,rv1108-evb", "rockchip,rv1108"; > - > -- Rockchip RK3368 evb: > - Required root node properties: > - - compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368"; > - > -- Rockchip R88 board: > - Required root node properties: > - - compatible = "rockchip,r88", "rockchip,rk3368"; > - > -- Rockchip RK3228 Evaluation board: > - Required root node properties: > - - compatible = "rockchip,rk3228-evb", "rockchip,rk3228"; > - > -- Rockchip RK3229 Evaluation board: > - - compatible = "rockchip,rk3229-evb", "rockchip,rk3229"; > - > -- Rockchip RK3288 Fennec board: > - Required root node properties: > - - compatible = "rockchip,rk3288-fennec", "rockchip,rk3288"; > - > -- Rockchip RK3328 evb: > - Required root node properties: > - - compatible = "rockchip,rk3328-evb", "rockchip,rk3328"; > - > -- Rockchip RK3399 evb: > - Required root node properties: > - - compatible = "rockchip,rk3399-evb", "rockchip,rk3399"; > - > -- Rockchip RK3399 Sapphire board standalone: > - Required root node properties: > - - compatible = "rockchip,rk3399-sapphire", "rockchip,rk3399"; > - > -- Rockchip RK3399 Sapphire Excavator board: > - Required root node properties: > - - compatible = "rockchip,rk3399-sapphire-excavator", "rockchip,rk3399"; > - > -- Theobroma Systems RK3368-uQ7 Haikou Baseboard: > - Required root node properties: > - - compatible = "tsd,rk3368-uq7-haikou", "rockchip,rk3368"; > - > -- Theobroma Systems RK3399-Q7 Haikou Baseboard: > - Required root node properties: > - - compatible = "tsd,rk3399-q7-haikou", "rockchip,rk3399"; > - > -- Tronsmart Orion R68 Meta > - Required root node properties: > - - compatible = "tronsmart,orion-r68-meta", "rockchip,rk3368"; > diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml > new file mode 100644 > index 000000000000..36f4bf4b445c > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml > @@ -0,0 +1,419 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/rockchip.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Rockchip platforms device tree bindings > + > +maintainers: > + - Heiko Stuebner <heiko@sntech.de> > + > +properties: > + $nodename: > + const: '/' > + compatible: > + oneOf: > + > + - description: 96boards RK3399 Ficus (ROCK960 Enterprise Edition) > + items: > + - const: vamrs,ficus > + - const: rockchip,rk3399 > + > + - description: 96boards RK3399 Rock960 (ROCK960 Consumer Edition) > + items: > + - const: vamrs,rock960 > + - const: rockchip,rk3399 > + > + - description: Amarula Vyasa RK3288 > + items: > + - const: amarula,vyasa-rk3288 > + - const: rockchip,rk3288 > + > + - description: Asus Tinker board > + items: > + - const: asus,rk3288-tinker > + - const: rockchip,rk3288 > + > + - description: Asus Tinker board S > + items: > + - const: asus,rk3288-tinker-s > + - const: rockchip,rk3288 > + > + - description: bq Curie 2 tablet > + items: > + - const: mundoreader,bq-curie2 > + - const: rockchip,rk3066a > + > + - description: bq Edison 2 Quad-Core tablet > + items: > + - const: mundoreader,bq-edison2qc > + - const: rockchip,rk3188 > + > + - description: ChipSPARK PopMetal-RK3288 > + items: > + - const: chipspark,popmetal-rk3288 > + - const: rockchip,rk3288 > + > + - description: ChipSPARK Rayeager PX2 > + items: > + - const: chipspark,rayeager-px2 > + - const: rockchip,rk3066a > + > + - description: Firefly Firefly-RK3288 > + items: > + - const: firefly,firefly-rk3288 > + - const: rockchip,rk3288 > + > + - description: Firefly Firefly-RK3288 (beta board) > + items: > + - const: firefly,firefly-rk3288-beta > + - const: rockchip,rk3288 > + > + - description: Firefly Firefly-RK3288 Reload > + items: > + - const: firefly,firefly-rk3288-reload > + - const: rockchip,rk3288 > + > + - description: Firefly Firefly-RK3399 > + items: > + - const: firefly,firefly-rk3399 > + - const: rockchip,rk3399 > + > + - description: Firefly roc-rk3328-cc > + items: > + - const: firefly,roc-rk3328-cc > + - const: rockchip,rk3328 > + > + - description: Firefly ROC-RK3399-PC > + items: > + - const: firefly,roc-rk3399-pc > + - const: rockchip,rk3399 > + > + - description: GeekBuying GeekBox > + items: > + - const: geekbuying,geekbox > + - const: rockchip,rk3368 > + > + - description: Google Bob (Asus Chromebook Flip C101PA) > + items: > + - const: google,bob-rev13 > + - const: google,bob-rev12 > + - const: google,bob-rev11 > + - const: google,bob-rev10 > + - const: google,bob-rev9 > + - const: google,bob-rev8 > + - const: google,bob-rev7 > + - const: google,bob-rev6 > + - const: google,bob-rev5 > + - const: google,bob-rev4 > + - const: google,bob > + - const: google,gru > + - const: rockchip,rk3399 > + > + - description: Google Brain (dev-board) > + items: > + - const: google,veyron-brain-rev0 > + - const: google,veyron-brain > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Gru (dev-board) > + items: > + - const: google,gru-rev15 > + - const: google,gru-rev14 > + - const: google,gru-rev13 > + - const: google,gru-rev12 > + - const: google,gru-rev11 > + - const: google,gru-rev10 > + - const: google,gru-rev9 > + - const: google,gru-rev8 > + - const: google,gru-rev7 > + - const: google,gru-rev6 > + - const: google,gru-rev5 > + - const: google,gru-rev4 > + - const: google,gru-rev3 > + - const: google,gru-rev2 > + - const: google,gru > + - const: rockchip,rk3399 > + > + - description: Google Jaq (Haier Chromebook 11 and more) > + items: > + - const: google,veyron-jaq-rev5 > + - const: google,veyron-jaq-rev4 > + - const: google,veyron-jaq-rev3 > + - const: google,veyron-jaq-rev2 > + - const: google,veyron-jaq-rev1 > + - const: google,veyron-jaq > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Jerry (Hisense Chromebook C11 and more) > + items: > + - const: google,veyron-jerry-rev7 > + - const: google,veyron-jerry-rev6 > + - const: google,veyron-jerry-rev5 > + - const: google,veyron-jerry-rev4 > + - const: google,veyron-jerry-rev3 > + - const: google,veyron-jerry > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Kevin (Samsung Chromebook Plus) > + items: > + - const: google,kevin-rev15 > + - const: google,kevin-rev14 > + - const: google,kevin-rev13 > + - const: google,kevin-rev12 > + - const: google,kevin-rev11 > + - const: google,kevin-rev10 > + - const: google,kevin-rev9 > + - const: google,kevin-rev8 > + - const: google,kevin-rev7 > + - const: google,kevin-rev6 > + - const: google,kevin > + - const: google,gru > + - const: rockchip,rk3399 > + > + - description: Google Mickey (Asus Chromebit CS10) > + items: > + - const: google,veyron-mickey-rev8 > + - const: google,veyron-mickey-rev7 > + - const: google,veyron-mickey-rev6 > + - const: google,veyron-mickey-rev5 > + - const: google,veyron-mickey-rev4 > + - const: google,veyron-mickey-rev3 > + - const: google,veyron-mickey-rev2 > + - const: google,veyron-mickey-rev1 > + - const: google,veyron-mickey-rev0 > + - const: google,veyron-mickey > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Minnie (Asus Chromebook Flip C100P) > + items: > + - const: google,veyron-minnie-rev4 > + - const: google,veyron-minnie-rev3 > + - const: google,veyron-minnie-rev2 > + - const: google,veyron-minnie-rev1 > + - const: google,veyron-minnie-rev0 > + - const: google,veyron-minnie > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Pinky (dev-board) > + items: > + - const: google,veyron-pinky-rev2 > + - const: google,veyron-pinky > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Google Scarlet - Kingdisplay (Acer Chromebook Tab 10) > + items: > + - const: google,scarlet-rev15-sku7 > + - const: google,scarlet-rev15 > + - const: google,scarlet-rev14-sku7 > + - const: google,scarlet-rev14 > + - const: google,scarlet-rev13-sku7 > + - const: google,scarlet-rev13 > + - const: google,scarlet-rev12-sku7 > + - const: google,scarlet-rev12 > + - const: google,scarlet-rev11-sku7 > + - const: google,scarlet-rev11 > + - const: google,scarlet-rev10-sku7 > + - const: google,scarlet-rev10 > + - const: google,scarlet-rev9-sku7 > + - const: google,scarlet-rev9 > + - const: google,scarlet-rev8-sku7 > + - const: google,scarlet-rev8 > + - const: google,scarlet-rev7-sku7 > + - const: google,scarlet-rev7 > + - const: google,scarlet-rev6-sku7 > + - const: google,scarlet-rev6 > + - const: google,scarlet-rev5-sku7 > + - const: google,scarlet-rev5 > + - const: google,scarlet-rev4-sku7 > + - const: google,scarlet-rev4 > + - const: google,scarlet-rev3-sku7 > + - const: google,scarlet-rev3 > + - const: google,scarlet > + - const: google,gru > + - const: rockchip,rk3399 > + > + - description: Google Scarlet - Innolux display (Acer Chromebook Tab 10) > + items: > + - const: google,scarlet-rev15-sku6 > + - const: google,scarlet-rev15 > + - const: google,scarlet-rev14-sku6 > + - const: google,scarlet-rev14 > + - const: google,scarlet-rev13-sku6 > + - const: google,scarlet-rev13 > + - const: google,scarlet-rev12-sku6 > + - const: google,scarlet-rev12 > + - const: google,scarlet-rev11-sku6 > + - const: google,scarlet-rev11 > + - const: google,scarlet-rev10-sku6 > + - const: google,scarlet-rev10 > + - const: google,scarlet-rev9-sku6 > + - const: google,scarlet-rev9 > + - const: google,scarlet-rev8-sku6 > + - const: google,scarlet-rev8 > + - const: google,scarlet-rev7-sku6 > + - const: google,scarlet-rev7 > + - const: google,scarlet-rev6-sku6 > + - const: google,scarlet-rev6 > + - const: google,scarlet-rev5-sku6 > + - const: google,scarlet-rev5 > + - const: google,scarlet-rev4-sku6 > + - const: google,scarlet-rev4 > + - const: google,scarlet > + - const: google,gru > + - const: rockchip,rk3399 > + > + - description: Google Speedy (Asus C201 Chromebook) > + items: > + - const: google,veyron-speedy-rev9 > + - const: google,veyron-speedy-rev8 > + - const: google,veyron-speedy-rev7 > + - const: google,veyron-speedy-rev6 > + - const: google,veyron-speedy-rev5 > + - const: google,veyron-speedy-rev4 > + - const: google,veyron-speedy-rev3 > + - const: google,veyron-speedy-rev2 > + - const: google,veyron-speedy > + - const: google,veyron > + - const: rockchip,rk3288 > + > + - description: Haoyu MarsBoard RK3066 > + items: > + - const: haoyu,marsboard-rk3066 > + - const: rockchip,rk3066a > + > + - description: mqmaker MiQi > + items: > + - const: mqmaker,miqi > + - const: rockchip,rk3288 > + > + - description: Netxeon R89 board > + items: > + - const: netxeon,r89 > + - const: rockchip,rk3288 > + > + - description: Phytec phyCORE-RK3288 Rapid Development Kit > + items: > + - const: phytec,rk3288-pcm-947 > + - const: phytec,rk3288-phycore-som > + - const: rockchip,rk3288 > + > + - description: Pine64 Rock64 > + items: > + - const: pine64,rock64 > + - const: rockchip,rk3328 > + > + - description: Pine64 RockPro64 > + items: > + - const: pine64,rockpro64 > + - const: rockchip,rk3399 > + > + - description: Radxa Rock > + items: > + - const: radxa,rock > + - const: rockchip,rk3188 > + > + - description: Radxa Rock2 Square > + items: > + - const: radxa,rock2-square > + - const: rockchip,rk3288 > + > + - description: Rikomagic MK808 v1 > + items: > + - const: rikomagic,mk808 > + - const: rockchip,rk3066a > + > + - description: Rockchip Kylin > + items: > + - const: rockchip,kylin-rk3036 > + - const: rockchip,rk3036 > + > + - description: Rockchip PX3 Evaluation board > + items: > + - const: rockchip,px3-evb > + - const: rockchip,px3 > + - const: rockchip,rk3188 > + > + - description: Rockchip PX30 Evaluation board > + items: > + - const: rockchip,px30-evb > + - const: rockchip,px30 > + > + - description: Rockchip PX5 Evaluation board > + items: > + - const: rockchip,px5-evb > + - const: rockchip,px5 > + - const: rockchip,rk3368 > + > + - description: Rockchip R88 > + items: > + - const: rockchip,r88 > + - const: rockchip,rk3368 > + > + - description: Rockchip RK3228 Evaluation board > + items: > + - const: rockchip,rk3228-evb > + - const: rockchip,rk3228 > + > + - description: Rockchip RK3288 Fennec > + items: > + - const: rockchip,rk3288-fennec > + - const: rockchip,rk3288 > + > + - description: Rockchip RK3229 Evaluation board > + items: > + - const: rockchip,rk3229-evb > + - const: rockchip,rk3229 > + > + - description: Rockchip RK3328 Evaluation board > + items: > + - const: rockchip,rk3328-evb > + - const: rockchip,rk3328 > + > + - description: Rockchip RK3368 Evaluation board (act8846 pmic) > + items: > + - const: rockchip,rk3368-evb-act8846 > + - const: rockchip,rk3368 > + > + - description: Rockchip RK3399 Evaluation board > + items: > + - const: rockchip,rk3399-evb > + - const: rockchip,rk3399 > + > + - description: Rockchip RK3399 Sapphire standalone > + items: > + - const: rockchip,rk3399-sapphire > + - const: rockchip,rk3399 > + > + - description: Rockchip RK3399 Sapphire with Excavator Baseboard > + items: > + - const: rockchip,rk3399-sapphire-excavator > + - const: rockchip,rk3399 > + > + - description: Rockchip RV1108 Evaluation board > + items: > + - const: rockchip,rv1108-evb > + - const: rockchip,rv1108 > + > + - description: Theobroma Systems RK3368-uQ7 with Haikou baseboard > + items: > + - const: tsd,rk3368-uq7-haikou > + - const: rockchip,rk3368 > + > + - description: Theobroma Systems RK3399-Q7 with Haikou baseboard > + items: > + - const: tsd,rk3399-q7-haikou > + - const: rockchip,rk3399 > + > + - description: Tronsmart Orion R68 Meta > + items: > + - const: tronsmart,orion-r68-meta > + - const: rockchip,rk3368 > +... >
On Thu, Dec 06, 2018 at 01:38:42PM -0600, Rob Herring wrote: > On Wed, Dec 5, 2018 at 1:44 PM Simon Horman <horms@verge.net.au> wrote: > > > > On Tue, Dec 04, 2018 at 09:08:57AM -0600, Rob Herring wrote: > > > On Tue, Dec 4, 2018 at 8:57 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > > > > Hi Simon, > > > > > > > > On Tue, Dec 4, 2018 at 3:48 PM Simon Horman <horms@verge.net.au> wrote: > > > > > On Mon, Dec 03, 2018 at 03:32:15PM -0600, 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> > > > > > > --- > > > > > > .../devicetree/bindings/arm/shmobile.txt | 151 ------------ > > > > > > .../devicetree/bindings/arm/shmobile.yaml | 218 ++++++++++++++++++ > > > > > > 2 files changed, 218 insertions(+), 151 deletions(-) > > > > > > delete mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt > > > > > > create mode 100644 Documentation/devicetree/bindings/arm/shmobile.yaml > > > > > > > > > > Hi Rob, > > > > > > > > > > what is this based on? I get a conflict when applying the .txt change > > > > > and if I knew the base for this patch it would be rather easy to work > > > > > out what has changed. > > > > > > 4.20-rc2 > > > > > > > > > > > > > Also, should we do an s/shmobile.txt/shmobile.yaml/ in MAINTAINERS? > > > > > > Yes. Though it was pointed out that get_maintainers.pl can pull emails > > > out of this file. We'd need to get that to work by default though. > > > > > > > Probably even s/shmobile.yaml/renesas.yaml/, while at it? > > > > > > Sure, if that's what you all want. > > > > How about this? > > LGTM Thanks. As my tree is already closed for v4.21 I have applied this for v4.22.
On Sun, Dec 9, 2018 at 4:14 PM Heiko Stuebner <heiko@sntech.de> wrote: > > Convert Rockchip SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Heiko Stuebner <heiko@sntech.de> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-rockchip@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > [move to per-board entries and added recently added boards] > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > --- > Hi Rob, > > there are boards where the description adds much value and on others > it is maybe less, but personally I'd like to keep things uniform, > as that makes reading these things easier if the format stays the > same all the time, so I've gone forward and just did the conversion > > make dtbs_check did not complain about the schema it seems but I > did end up with an error later on: > > FATAL ERROR: Unknown output format "yaml" > make[2]: *** [scripts/Makefile.lib:313: arch/arm/boot/dts/rk3036-evb.dt.yaml] Fehler 1 You need libyaml and its headers installed so dtc can output yaml, but that's not needed for checking the schema against the meta-schema. > But I guess I did not mess up the schema yet. > > So does it look ok that way? Yes, but one comment... > + - description: Firefly Firefly-RK3288 > + items: > + - const: firefly,firefly-rk3288 > + - const: rockchip,rk3288 > + > + - description: Firefly Firefly-RK3288 (beta board) > + items: > + - const: firefly,firefly-rk3288-beta > + - const: rockchip,rk3288 > + > + - description: Firefly Firefly-RK3288 Reload Seems like combining these 3 (or first 2?) would make sense if this is just revs of the same board. But either way is fine. > + items: > + - const: firefly,firefly-rk3288-reload > + - const: rockchip,rk3288
On Fri, Dec 7, 2018 at 10:47 PM Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > > Hi Rob, > > > On Tue, Dec 4, 2018 at 6:32 AM Rob Herring <robh@kernel.org> wrote: > > > > This adds the build infrastructure for checking DT binding schema > > documents and validating dts files using the binding schema. > > > > Check DT binding schema documents: > > make dt_binding_check > > > > Build dts files and check using DT binding schema: > > make dtbs_check > > > > Optionally, DT_SCHEMA_FILES can passed in with a schema file(s) to use > > for validation. This makes it easier to find and fix errors generated by > > a specific schema. > > > > Currently, the validation targets are separate from a normal build to > > avoid a hard dependency on the external DT schema project and because > > there are lots of warnings generated. > > > > Cc: Jonathan Corbet <corbet@lwn.net> > > Cc: Mark Rutland <mark.rutland@arm.com> > > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > > Cc: Michal Marek <michal.lkml@markovi.net> > > Cc: linux-doc@vger.kernel.org > > Cc: devicetree@vger.kernel.org > > Cc: linux-kbuild@vger.kernel.org > > Signed-off-by: Rob Herring <robh@kernel.org> > > --- > > .gitignore | 1 + > > Documentation/Makefile | 2 +- > > Documentation/devicetree/bindings/.gitignore | 1 + > > Documentation/devicetree/bindings/Makefile | 33 ++++++++++++++++++++ > > Makefile | 11 +++++-- > > scripts/Makefile.lib | 24 ++++++++++++-- > > 6 files changed, 67 insertions(+), 5 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/.gitignore > > create mode 100644 Documentation/devicetree/bindings/Makefile > > > > diff --git a/.gitignore b/.gitignore > > index 97ba6b79834c..a20ac26aa2f5 100644 > > --- a/.gitignore > > +++ b/.gitignore > > @@ -15,6 +15,7 @@ > > *.bin > > *.bz2 > > *.c.[012]*.* > > +*.dt.yaml > > *.dtb > > *.dtb.S > > *.dwo > > diff --git a/Documentation/Makefile b/Documentation/Makefile > > index 2ca77ad0f238..9786957c6a35 100644 > > --- a/Documentation/Makefile > > +++ b/Documentation/Makefile > > @@ -2,7 +2,7 @@ > > # Makefile for Sphinx documentation > > # > > > > -subdir-y := > > +subdir-y := devicetree/bindings/ > > > > # You can set these variables from the command line. > > SPHINXBUILD = sphinx-build > > diff --git a/Documentation/devicetree/bindings/.gitignore b/Documentation/devicetree/bindings/.gitignore > > new file mode 100644 > > index 000000000000..d9194c02dd08 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/.gitignore > > @@ -0,0 +1 @@ > > +*.example.dts > > diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile > > new file mode 100644 > > index 000000000000..ee0110dd8131 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/Makefile > > @@ -0,0 +1,33 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +DT_DOC_CHECKER ?= dt-doc-validate > > +DT_EXTRACT_EX ?= dt-extract-example > > +DT_MK_SCHEMA ?= dt-mk-schema > > +DT_MK_SCHEMA_FLAGS := $(if $(DT_SCHEMA_FILES), -u) > > + > > +quiet_cmd_chk_binding = CHKDT $< > > + cmd_chk_binding = (set -e; \ > > + $(DT_DOC_CHECKER) $< ; \ > > + mkdir -p $(dir $@) ; \ > > + $(DT_EXTRACT_EX) $< > $@ ) > > + > > +$(obj)/%.example.dts: $(src)/%.yaml FORCE > > + $(call if_changed,chk_binding) > > + > > +DT_TMP_SCHEMA := .schema.yaml.tmp > > +extra-y += $(DT_TMP_SCHEMA) > > + > > +quiet_cmd_mk_schema = SCHEMA $@ > > + cmd_mk_schema = mkdir -p $(obj); \ > > + rm -f $@; \ > > + $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $< > > > I think '$<' is wrong. > > '$<' is replaced with the first prerequisite. Indeed. > You can easily check what is happening here. > > $ cat Documentation/devicetree/bindings/..schema.yaml.tmp.cmd > cmd_Documentation/devicetree/bindings/.schema.yaml.tmp := mkdir -p > Documentation/devicetree/bindings; rm -f > Documentation/devicetree/bindings/.schema.yaml.tmp; dt-mk-schema -o > Documentation/devicetree/bindings/.schema.yaml.tmp > Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml > > > So, the dt-validater will check only binding from ti,davinci.yaml, > which is almost useless. > > > > If I understand it correctly, > .schema.yaml.tmp should contain all binding yaml. > > > I fixed it up like follows: > > diff --git a/Documentation/devicetree/bindings/Makefile > b/Documentation/devicetree/bindings/Makefile > index ee0110d..267458f 100644 > --- a/Documentation/devicetree/bindings/Makefile > +++ b/Documentation/devicetree/bindings/Makefile > @@ -19,7 +19,7 @@ extra-y += $(DT_TMP_SCHEMA) > quiet_cmd_mk_schema = SCHEMA $@ > cmd_mk_schema = mkdir -p $(obj); \ > rm -f $@; \ > - $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $< > + $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ > $(filter-out FORCE, $^) Thanks, I incorporated this fix. > > DT_DOCS = $(shell cd $(srctree)/$(src) && find * -name '*.yaml') > DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS)) > > > > Then, I see another error. I fixed this with this change: @@ -27,7 +27,7 @@ DT_SCHEMA_FILES ?= $(addprefix $(src)/,$(DT_DOCS)) extra-y += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES)) extra-y += $(patsubst $(src)/%.yaml,%.example.dtb, $(DT_SCHEMA_FILES)) -$(obj)/$(DT_TMP_SCHEMA): $(addprefix $(obj)/,$(patsubst $(src)/%.yaml,%.example.dtb, $(DT_SCHEMA_FILES))) +$(obj)/$(DT_TMP_SCHEMA): | $(addprefix $(obj)/,$(patsubst $(src)/%.yaml,%.example.dtb, $(DT_SCHEMA_FILES))) $(obj)/$(DT_TMP_SCHEMA): $(addprefix $(srctree)/, $(DT_SCHEMA_FILES)) FORCE $(call if_changed,mk_schema) > > > SCHEMA Documentation/devicetree/bindings/.schema.yaml.tmp > Traceback (most recent call last): > File "/home/masahiro/ref/yaml-bindings/tools/dt-mk-schema", line 32, > in <module> > schemas = dtschema.process_schemas(args.schemas, core_schema=(not > args.useronly)) > File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py", > line 359, in process_schemas > sch = process_schema(os.path.abspath(filename)) > File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py", > line 314, in process_schema > schema = load_schema(filename) > File "/usr/local/lib/python3.5/dist-packages/dtschema-0.0.1-py3.5.egg/dtschema/lib.py", > line 80, in load_schema > return yaml.load(f.read()) > File "/usr/lib/python3.5/codecs.py", line 321, in decode > (result, consumed) = self._buffer_decode(data, self.errors, final) > UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd0 in position > 0: invalid continuation byte > Documentation/devicetree/bindings/Makefile:33: recipe for target > 'Documentation/devicetree/bindings/.schema.yaml.tmp' failed > make[1]: *** [Documentation/devicetree/bindings/.schema.yaml.tmp] Error 1 > Makefile:1278: recipe for target 'dt_binding_check' failed > make: *** [dt_binding_check] Error 2 > > > > > > > > BTW, I cannot build *.dt.yaml > > > > DTC arch/arm/boot/dts/alpine-db.dt.yaml > FATAL ERROR: Unknown output format "yaml" > scripts/Makefile.lib:313: recipe for target > 'arch/arm/boot/dts/alpine-db.dt.yaml' failed > make[1]: *** [arch/arm/boot/dts/alpine-db.dt.yaml] Error 1 > make[1]: *** Deleting file 'arch/arm/boot/dts/alpine-db.dt.yaml' > Makefile:1262: recipe for target 'dtbs_check' failed > > > > > I use linux-next. > > > script/dtc/dtc does not understand '-O yaml' > > > I also tried the upstream DTC project with no success. > > > Where can I get dtc with yaml support? You need libyaml and its headers. I'll try to make this a better error message. For now, libyaml is optional so we don't break everyone just building dtbs. Rob
On Mon, Dec 10, 2018 at 4:45 PM Heiko Stuebner <heiko@sntech.de> wrote: > > From: Rob Herring <robh@kernel.org> > > Convert Rockchip SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: Heiko Stuebner <heiko@sntech.de> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-rockchip@lists.infradead.org > Signed-off-by: Rob Herring <robh@kernel.org> > [move to per-board entries and added recently added boards] > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > --- > Hi Rob, > > thanks for the libyaml hint, now dtc does check my dts nicely and > emits quite a number of little complaints ;-) . > > Also that suggestion to move the original firefly release+beta boards > together was great and I just did that. > > Should look ok now, if so I'll apply it tomorrow. LGTM
On Tue, Dec 4, 2018 at 10:18 PM Rob Herring <robh@kernel.org> wrote: > > On Tue, Dec 4, 2018 at 7:01 PM Kevin Hilman <khilman@baylibre.com> wrote: > > > > Rob Herring <robh@kernel.org> writes: > > > > > It is best practice to have 1 binding per file, so board level bindings > > > should be separate for various misc SoC bindings. > > > > > > Cc: Mark Rutland <mark.rutland@arm.com> > > > Cc: Carlo Caione <carlo@caione.org> > > > Cc: Kevin Hilman <khilman@baylibre.com> > > > Cc: devicetree@vger.kernel.org > > > Cc: linux-arm-kernel@lists.infradead.org > > > Cc: linux-amlogic@lists.infradead.org > > > Signed-off-by: Rob Herring <robh@kernel.org> > > > --- > > > .../devicetree/bindings/arm/amlogic.txt | 29 ------------------- > > > .../amlogic/amlogic,meson-gx-ao-secure.txt | 28 ++++++++++++++++++ > > > 2 files changed, 28 insertions(+), 29 deletions(-) > > > create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt > > > > Acked-by: Kevin Hilman <khilman@baylibre.com> > > > > But this isn't really related to the schema series is it? If you > > prefer, I can just queue this one separately via my tree. > > Yes, you can take it. Hey Kevin, doesn't look like this got applied. Rob
On Sat, Dec 08, 2018 at 09:58:37AM +0800, Shawn Guo wrote: > On Thu, Dec 06, 2018 at 05:33:13PM -0600, Rob Herring wrote: > > On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo <shawnguo@kernel.org> wrote: > > > > > > On Mon, Dec 03, 2018 at 03:32:07PM -0600, 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 | 229 ------------------ > > > > .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++++++++++ > > > > > > Rob, > > > > > > I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my > > > tree, so please send it via your tree. > > > > What about: > > > > c386f362957b dt-bindings: Add compatible string for LS1028A-QDS > > 3671cd57de06 dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding > > Ah, sorry, I only checked on imx/dt branch and forgot imx/dt64. I will > drop the changes on fsl.txt and update fsl.yaml after it hits mainline. What happened to this? It seems the patch did not hit v5.0-rc1. Shawn
On 10.1.2019 07:42, Shawn Guo wrote: > On Sat, Dec 08, 2018 at 09:58:37AM +0800, Shawn Guo wrote: >> On Thu, Dec 06, 2018 at 05:33:13PM -0600, Rob Herring wrote: >>> On Wed, Dec 5, 2018 at 8:32 PM Shawn Guo <shawnguo@kernel.org> wrote: >>>> >>>> On Mon, Dec 03, 2018 at 03:32:07PM -0600, 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 | 229 ------------------ >>>>> .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++++++++++ >>>> >>>> Rob, >>>> >>>> I do have any changes on bindings/arm/fsl.txt queued for 4.21 on my >>>> tree, so please send it via your tree. >>> >>> What about: >>> >>> c386f362957b dt-bindings: Add compatible string for LS1028A-QDS >>> 3671cd57de06 dt-bindings: ls1012a: Add FRWY-LS1012A device tree binding >> >> Ah, sorry, I only checked on imx/dt branch and forgot imx/dt64. I will >> drop the changes on fsl.txt and update fsl.yaml after it hits mainline. > > What happened to this? It seems the patch did not hit v5.0-rc1. Hi Shawn, Rob actually asked you a similar question two days ago.. https://lkml.org/lkml/2019/1/8/754
On Thu, Jan 10, 2019 at 10:44:03AM +0000, Vokáč Michal wrote: ... > > What happened to this? It seems the patch did not hit v5.0-rc1. > > Hi Shawn, > Rob actually asked you a similar question two days ago.. > > https://lkml.org/lkml/2019/1/8/754 Oops, it seems there were some miscommunication between Rob and me. Let me fix this by queuing this patch on my tree now. Shawn
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. This series 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. My plan is to merge this initial support for v4.21. There's not yet any requirement that new bindings be submitted using the schema. I think that should wait a bit until after this gets a bit more exposure. I do have some tooling in place to test submitted patches and update DT patchwork with the result. SoC maintainers, The board/soc bindings can go thru your trees if there are conflicts (if any SoC or board is added). It shouldn't matter if they go in separately from the build support. shmobile, rockchip, fsl and amlogic already have conflicts with next. Otherwise, I can take them via the DT tree. Rob v2: - Rebase to v4.20-rc2 - Add some missing Xilinx boards (from Michal Simek) - Add ability to validate with a single specified schema using the DT_SCHEMA_FILES variable. - Add back some dropped comments for board names - Various maintainer fixes - Rework ARM PMU interrupts schema. - Updates to ARM CPU vendor specific properties. - Add i2c-gpio conversion to json-schema. Serves as example of including another schema (i2c-controller.yaml) - Set license on schema files to GPL-2.0 - Improvements to writing-schema.md and annotated example. [1] https://github.com/robherring/yaml-bindings [2] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git yaml-bindings-v2 Michal Simek (1): dt-bindings: arm: Add missing Xilinx boards Rob Herring (33): 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: i2c: Convert i2c-gpio 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: amlogic: Move 'amlogic,meson-gx-ao-secure' binding to its own file 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: renesas: Move 'renesas,prr' binding to its own doc 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 | 1 + Documentation/devicetree/bindings/Makefile | 33 ++ .../devicetree/bindings/arm/actions.txt | 56 -- .../devicetree/bindings/arm/actions.yaml | 38 ++ .../devicetree/bindings/arm/al,alpine.txt | 16 - .../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 | 31 ++ .../devicetree/bindings/arm/amlogic.txt | 138 ----- .../devicetree/bindings/arm/amlogic.yaml | 109 ++++ .../amlogic/amlogic,meson-gx-ao-secure.txt | 28 + .../devicetree/bindings/arm/armadeus.txt | 6 - .../devicetree/bindings/arm/atmel-at91.txt | 72 --- .../devicetree/bindings/arm/atmel-at91.yaml | 133 +++++ 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 - .../devicetree/bindings/arm/cpus.txt | 490 ----------------- .../devicetree/bindings/arm/cpus.yaml | 507 ++++++++++++++++++ .../devicetree/bindings/arm/davinci.txt | 25 - Documentation/devicetree/bindings/arm/fsl.txt | 229 -------- .../devicetree/bindings/arm/fsl.yaml | 214 ++++++++ .../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 | 91 ++++ .../devicetree/bindings/arm/primecell.txt | 46 -- .../devicetree/bindings/arm/primecell.yaml | 36 ++ .../devicetree/bindings/arm/qcom.txt | 57 -- .../devicetree/bindings/arm/qcom.yaml | 125 +++++ .../devicetree/bindings/arm/realtek.txt | 22 - .../devicetree/bindings/arm/realtek.yaml | 23 + .../devicetree/bindings/arm/renesas,prr.txt | 20 + .../devicetree/bindings/arm/rockchip.txt | 240 --------- .../devicetree/bindings/arm/rockchip.yaml | 251 +++++++++ .../devicetree/bindings/arm/shmobile.txt | 169 ------ .../devicetree/bindings/arm/shmobile.yaml | 218 ++++++++ .../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 | 65 --- .../devicetree/bindings/arm/tegra.yaml | 101 ++++ .../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 | 114 ++++ Documentation/devicetree/bindings/arm/zte.txt | 14 - .../devicetree/bindings/arm/zte.yaml | 26 + .../devicetree/bindings/example-schema.yaml | 170 ++++++ .../devicetree/bindings/i2c/i2c-gpio.txt | 46 -- .../devicetree/bindings/i2c/i2c-gpio.yaml | 73 +++ .../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 | 190 ------- .../devicetree/bindings/trivial-devices.yaml | 392 ++++++++++++++ Documentation/devicetree/writing-schema.md | 130 +++++ Makefile | 11 +- scripts/Makefile.lib | 24 +- 77 files changed, 3487 insertions(+), 2493 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 delete mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.txt create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml 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 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 delete mode 100644 Documentation/devicetree/bindings/arm/zte.txt create mode 100644 Documentation/devicetree/bindings/arm/zte.yaml create mode 100644 Documentation/devicetree/bindings/example-schema.yaml delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-gpio.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-gpio.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.19.1