Convert the device tree bindings for the Amlogic audio memory arbiter
controller to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Kevin Hilman <[email protected]>
Cc: Jerome Brunet <[email protected]>
Cc: Martin Blumenstingl <[email protected]>
---
.../reset/amlogic,meson-axg-audio-arb.txt | 22 --------
.../reset/amlogic,meson-axg-audio-arb.yaml | 56 +++++++++++++++++++
2 files changed, 56 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.txt
create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.txt
deleted file mode 100644
index 43e580ef64ba..000000000000
--- a/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-* Amlogic audio memory arbiter controller
-
-The Amlogic Audio ARB is a simple device which enables or
-disables the access of Audio FIFOs to DDR on AXG based SoC.
-
-Required properties:
-- compatible: 'amlogic,meson-axg-audio-arb' or
- 'amlogic,meson-sm1-audio-arb'
-- reg: physical base address of the controller and length of memory
- mapped region.
-- clocks: phandle to the fifo peripheral clock provided by the audio
- clock controller.
-- #reset-cells: must be 1.
-
-Example on the A113 SoC:
-
-arb: reset-controller@280 {
- compatible = "amlogic,meson-axg-audio-arb";
- reg = <0x0 0x280 0x0 0x4>;
- #reset-cells = <1>;
- clocks = <&clkc_audio AUD_CLKID_DDR_ARB>;
-};
diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml b/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml
new file mode 100644
index 000000000000..704a502adc5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/amlogic,meson-axg-audio-arb.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Amlogic audio memory arbiter controller
+
+maintainers:
+ - Jerome Brunet <[email protected]>
+
+description: The Amlogic Audio ARB is a simple device which enables or disables
+ the access of Audio FIFOs to DDR on AXG based SoC.
+
+properties:
+ compatible:
+ enum:
+ - amlogic,meson-axg-audio-arb
+ - amlogic,meson-sm1-audio-arb
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+ description: |
+ phandle to the fifo peripheral clock provided by the audio clock
+ controller.
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ // on the A113 SoC:
+ #include <dt-bindings/clock/axg-audio-clkc.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ arb: reset-controller@280 {
+ compatible = "amlogic,meson-axg-audio-arb";
+ reg = <0x0 0x280 0x0 0x4>;
+ #reset-cells = <1>;
+ clocks = <&clkc_audio AUD_CLKID_DDR_ARB>;
+ };
+ };
--
2.30.2
Convert the device tree bindings for the Qualcomm Atheros AR7xxx/AR9XXX
reset controller to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Alban Bedel <[email protected]>
---
.../devicetree/bindings/reset/ath79-reset.txt | 20 ----------
.../bindings/reset/qca,ar7100-reset.yaml | 40 +++++++++++++++++++
2 files changed, 40 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/ath79-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/ath79-reset.txt b/Documentation/devicetree/bindings/reset/ath79-reset.txt
deleted file mode 100644
index 4c56330bf398..000000000000
--- a/Documentation/devicetree/bindings/reset/ath79-reset.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Binding for Qualcomm Atheros AR7xxx/AR9XXX reset controller
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required Properties:
-- compatible: has to be "qca,<soctype>-reset", "qca,ar7100-reset"
- as fallback
-- reg: Base address and size of the controllers memory area
-- #reset-cells : Specifies the number of cells needed to encode reset
- line, should be 1
-
-Example:
-
- reset-controller@1806001c {
- compatible = "qca,ar9132-reset", "qca,ar7100-reset";
- reg = <0x1806001c 0x4>;
-
- #reset-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml b/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml
new file mode 100644
index 000000000000..9be60e55cd71
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2015 Alban Bedel <[email protected]>
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/qca,ar7100-reset.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Qualcomm Atheros AR7xxx/AR9XXX reset controller
+
+maintainers:
+ - Alban Bedel <[email protected]>
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - qca,ar9132-reset
+ - qca,ar9331-reset
+ - const: qca,ar7100-reset
+
+ reg:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ reset-controller@1806001c {
+ compatible = "qca,ar9132-reset", "qca,ar7100-reset";
+ reg = <0x1806001c 0x4>;
+ #reset-cells = <1>;
+ };
--
2.30.2
Convert the device tree bindings for the Altera SOCFPGA reset manager to
YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Dinh Nguyen <[email protected]>
---
.../bindings/reset/altr,rst-mgr.yaml | 47 +++++++++++++++++++
.../bindings/reset/socfpga-reset.txt | 16 -------
2 files changed, 47 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
delete mode 100644 Documentation/devicetree/bindings/reset/socfpga-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
new file mode 100644
index 000000000000..4379cec6b35a
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/altr,rst-mgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Altera SOCFPGA Reset Manager
+
+maintainers:
+ - Dinh Nguyen <[email protected]>
+
+properties:
+ compatible:
+ oneOf:
+ - description: Cyclone5/Arria5/Arria10
+ const: altr,rst-mgr
+ - description: Stratix10 ARM64 SoC
+ items:
+ - const: altr,stratix10-rst-mgr
+ - const: altr,rst-mgr
+
+ reg:
+ maxItems: 1
+
+ altr,modrst-offset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: Offset of the first modrst register
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - altr,modrst-offset
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ rstmgr@ffd05000 {
+ compatible = "altr,rst-mgr";
+ reg = <0xffd05000 0x1000>;
+ altr,modrst-offset = <0x10>;
+ #reset-cells = <1>;
+ };
diff --git a/Documentation/devicetree/bindings/reset/socfpga-reset.txt b/Documentation/devicetree/bindings/reset/socfpga-reset.txt
deleted file mode 100644
index 38fe34fd8b8a..000000000000
--- a/Documentation/devicetree/bindings/reset/socfpga-reset.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Altera SOCFPGA Reset Manager
-
-Required properties:
-- compatible : "altr,rst-mgr" for (Cyclone5/Arria5/Arria10)
- "altr,stratix10-rst-mgr","altr,rst-mgr" for Stratix10 ARM64 SoC
-- reg : Should contain 1 register ranges(address and length)
-- altr,modrst-offset : Should contain the offset of the first modrst register.
-- #reset-cells: 1
-
-Example:
- rstmgr@ffd05000 {
- #reset-cells = <1>;
- compatible = "altr,rst-mgr";
- reg = <0xffd05000 0x1000>;
- altr,modrst-offset = <0x10>;
- };
--
2.30.2
Convert the common reset controller and reset consumer device tree
bindings to YAML schema.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Stephen Warren <[email protected]>
---
.../bindings/reset/reset-consumer.yaml | 72 ++++++++++++++++++
.../bindings/reset/reset-controller.yaml | 50 +++++++++++++
.../devicetree/bindings/reset/reset.txt | 75 -------------------
3 files changed, 122 insertions(+), 75 deletions(-)
create mode 100644 Documentation/devicetree/bindings/reset/reset-consumer.yaml
create mode 100644 Documentation/devicetree/bindings/reset/reset-controller.yaml
delete mode 100644 Documentation/devicetree/bindings/reset/reset.txt
diff --git a/Documentation/devicetree/bindings/reset/reset-consumer.yaml b/Documentation/devicetree/bindings/reset/reset-consumer.yaml
new file mode 100644
index 000000000000..e17229eb49c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset-consumer.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright 2012 Stephen Warren <[email protected]>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/reset-consumer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common reset signal consumer bindings
+
+maintainers:
+ - Philipp Zabel <[email protected]>
+
+description: |
+ Hardware blocks typically receive a reset signal. This signal is generated by
+ a reset provider (e.g. power management or clock module) and received by a
+ reset consumer (the module being reset, or a module managing when a sub-
+ ordinate module is reset). This binding exists to represent the consumers of
+ reset signals provided by reset controllers.
+
+ A reset signal is represented by the phandle of the provider, plus a reset
+ specifier - a list of DT cells that represents the reset signal within the
+ provider. The length (number of cells) and semantics of the reset specifier
+ are dictated by the binding of the reset provider, although common schemes
+ are described below.
+
+ A word on where to place reset signal consumers in device tree: It is possible
+ in hardware for a reset signal to affect multiple logically separate HW blocks
+ at once. In this case, it would be unwise to represent this reset signal in
+ the DT node of each affected HW block, since if activated, an unrelated block
+ may be reset. Instead, reset signals should be represented in the DT node
+ where it makes most sense to control it; this may be a bus node if all
+ children of the bus are affected by the reset signal, or an individual HW
+ block node for dedicated reset signals. The intent of this binding is to give
+ appropriate software access to the reset signals in order to manage the HW,
+ rather than to slavishly enumerate the reset signal that affects each HW
+ block.
+
+select: true
+
+properties:
+ resets:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ List of phandle and reset specifier pairs, one pair for each reset signal
+ that affects the device, or that the device manages.
+ Note: if the reset provider specifies '0' for "#reset-cells", then only
+ the phandle portion of the pair will appear.
+
+ reset-names:
+ description: |
+ List of reset signal name strings sorted in the same order as the resets
+ property. Consumers drivers will use "reset-names" to match reset signal
+ names with reset specifiers.
+
+additionalProperties: true
+
+examples:
+ - |
+ // A device with a single reset signal named "reset".
+ device {
+ resets = <&rst 20>;
+ reset-names = "reset";
+ };
+ - |
+ // A bus that controls the reset signal of each of four subordinate
+ // devices. Consider for example a bus that fails to operate unless no
+ // child device has reset asserted.
+ bus {
+ resets = <&rst 10>, <&rst 11>, <&rst 12>, <&rst 11>;
+ reset-names = "i2s1", "i2s2", "dma", "mixer";
+ };
+...
diff --git a/Documentation/devicetree/bindings/reset/reset-controller.yaml b/Documentation/devicetree/bindings/reset/reset-controller.yaml
new file mode 100644
index 000000000000..33468f94f4c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/reset-controller.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+# Copyright 2021 Stephen Warren <[email protected]>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/reset-controller.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common reset controller provider bindings
+
+maintainers:
+ - Philipp Zabel <[email protected]>
+
+description: |
+ This binding is intended to represent the hardware reset signals present
+ internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
+ standalone chips are most likely better represented as GPIOs, although there
+ are likely to be exceptions to this rule.
+
+ Hardware blocks typically receive a reset signal. This signal is generated by
+ a reset provider (e.g. power management or clock module) and received by a
+ reset consumer (the module being reset, or a module managing when a sub-
+ ordinate module is reset). This binding exists to represent the provider of
+ one or more reset signals.
+
+select:
+ anyOf:
+ - properties:
+ $nodename:
+ pattern: '^reset-controller'
+ - required:
+ - '#reset-cells'
+
+properties:
+ '#reset-cells':
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+additionalProperties: true
+
+examples:
+ - |
+ // A reset controller providing multiple reset controls
+ rst: reset-controller {
+ #reset-cells = <1>;
+ };
+
+ // A reset consumer receiving a single reset signal with index 0
+ peripheral {
+ resets = <&rst 0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/reset/reset.txt b/Documentation/devicetree/bindings/reset/reset.txt
deleted file mode 100644
index 31db6ff84908..000000000000
--- a/Documentation/devicetree/bindings/reset/reset.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-= Reset Signal Device Tree Bindings =
-
-This binding is intended to represent the hardware reset signals present
-internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
-standalone chips are most likely better represented as GPIOs, although there
-are likely to be exceptions to this rule.
-
-Hardware blocks typically receive a reset signal. This signal is generated by
-a reset provider (e.g. power management or clock module) and received by a
-reset consumer (the module being reset, or a module managing when a sub-
-ordinate module is reset). This binding exists to represent the provider and
-consumer, and provide a way to couple the two together.
-
-A reset signal is represented by the phandle of the provider, plus a reset
-specifier - a list of DT cells that represents the reset signal within the
-provider. The length (number of cells) and semantics of the reset specifier
-are dictated by the binding of the reset provider, although common schemes
-are described below.
-
-A word on where to place reset signal consumers in device tree: It is possible
-in hardware for a reset signal to affect multiple logically separate HW blocks
-at once. In this case, it would be unwise to represent this reset signal in
-the DT node of each affected HW block, since if activated, an unrelated block
-may be reset. Instead, reset signals should be represented in the DT node
-where it makes most sense to control it; this may be a bus node if all
-children of the bus are affected by the reset signal, or an individual HW
-block node for dedicated reset signals. The intent of this binding is to give
-appropriate software access to the reset signals in order to manage the HW,
-rather than to slavishly enumerate the reset signal that affects each HW
-block.
-
-= Reset providers =
-
-Required properties:
-#reset-cells: Number of cells in a reset specifier; Typically 0 for nodes
- with a single reset output and 1 for nodes with multiple
- reset outputs.
-
-For example:
-
- rst: reset-controller {
- #reset-cells = <1>;
- };
-
-= Reset consumers =
-
-Required properties:
-resets: List of phandle and reset specifier pairs, one pair
- for each reset signal that affects the device, or that the
- device manages. Note: if the reset provider specifies '0' for
- #reset-cells, then only the phandle portion of the pair will
- appear.
-
-Optional properties:
-reset-names: List of reset signal name strings sorted in the same order as
- the resets property. Consumers drivers will use reset-names to
- match reset signal names with reset specifiers.
-
-For example:
-
- device {
- resets = <&rst 20>;
- reset-names = "reset";
- };
-
-This represents a device with a single reset signal named "reset".
-
- bus {
- resets = <&rst 10> <&rst 11> <&rst 12> <&rst 11>;
- reset-names = "i2s1", "i2s2", "dma", "mixer";
- };
-
-This represents a bus that controls the reset signal of each of four sub-
-ordinate devices. Consider for example a bus that fails to operate unless no
-child device has reset asserted.
--
2.30.2
Convert the device tree bindings for the Bitmain BM1880 reset controller
to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Manivannan Sadhasivam <[email protected]>
---
.../bindings/reset/bitmain,bm1880-reset.txt | 18 ----------
.../bindings/reset/bitmain,bm1880-reset.yaml | 36 +++++++++++++++++++
2 files changed, 36 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt
deleted file mode 100644
index a6f8455ae6c4..000000000000
--- a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Bitmain BM1880 SoC Reset Controller
-===================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-- compatible: Should be "bitmain,bm1880-reset"
-- reg: Offset and length of reset controller space in SCTRL.
-- #reset-cells: Must be 1.
-
-Example:
-
- rst: reset-controller@c00 {
- compatible = "bitmain,bm1880-reset";
- reg = <0xc00 0x8>;
- #reset-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml
new file mode 100644
index 000000000000..f0aca744388c
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Manivannan Sadhasivam <[email protected]>
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/bitmain,bm1880-reset.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Bitmain BM1880 SoC Reset Controller
+
+maintainers:
+ - Manivannan Sadhasivam <[email protected]>
+
+properties:
+ compatible:
+ const: bitmain,bm1880-reset
+
+ reg:
+ maxItems: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ rst: reset-controller@c00 {
+ compatible = "bitmain,bm1880-reset";
+ reg = <0xc00 0x8>;
+ #reset-cells = <1>;
+ };
--
2.30.2
Convert the device tree bindings for the Marvell Berlin reset controller
to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Antoine Tenart <[email protected]>
---
.../bindings/reset/berlin,reset.txt | 23 -----------
.../bindings/reset/marvell,berlin2-reset.yaml | 38 +++++++++++++++++++
2 files changed, 38 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/berlin,reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/berlin,reset.txt b/Documentation/devicetree/bindings/reset/berlin,reset.txt
deleted file mode 100644
index 514fee098b4b..000000000000
--- a/Documentation/devicetree/bindings/reset/berlin,reset.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-Marvell Berlin reset controller
-===============================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-The reset controller node must be a sub-node of the chip controller
-node on Berlin SoCs.
-
-Required properties:
-- compatible: should be "marvell,berlin2-reset"
-- #reset-cells: must be set to 2
-
-Example:
-
-chip_rst: reset {
- compatible = "marvell,berlin2-reset";
- #reset-cells = <2>;
-};
-
-&usb_phy0 {
- resets = <&chip_rst 0x104 12>;
-};
diff --git a/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml b/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml
new file mode 100644
index 000000000000..d71d0f0a13ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2015 Antoine Tenart <[email protected]>
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/reset/marvell,berlin2-reset.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Marvell Berlin reset controller
+
+maintainers:
+ - Antoine Tenart <[email protected]>
+
+description: The reset controller node must be a sub-node of the chip
+ controller node on Berlin SoCs.
+
+properties:
+ compatible:
+ const: marvell,berlin2-reset
+
+ "#reset-cells":
+ const: 2
+
+required:
+ - compatible
+ - "#reset-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ chip: chip-control@ea0000 {
+ reg = <0xea0000 0x400>;
+
+ chip_rst: reset {
+ compatible = "marvell,berlin2-reset";
+ #reset-cells = <2>;
+ };
+ };
--
2.30.2
Convert the device tree bindings for the Lantiq XWAY SoC RCU reset
controller to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Martin Blumenstingl <[email protected]>
---
.../bindings/reset/lantiq,reset.txt | 30 ------------
.../bindings/reset/lantiq,reset.yaml | 49 +++++++++++++++++++
2 files changed, 49 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/lantiq,reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/lantiq,reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/lantiq,reset.txt b/Documentation/devicetree/bindings/reset/lantiq,reset.txt
deleted file mode 100644
index c6aef36b7d15..000000000000
--- a/Documentation/devicetree/bindings/reset/lantiq,reset.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Lantiq XWAY SoC RCU reset controller binding
-============================================
-
-This binding describes a reset-controller found on the RCU module on Lantiq
-XWAY SoCs.
-
-This node has to be a sub node of the Lantiq RCU block.
-
--------------------------------------------------------------------------------
-Required properties:
-- compatible : Should be one of
- "lantiq,danube-reset"
- "lantiq,xrx200-reset"
-- reg : Defines the following sets of registers in the parent
- syscon device
- - Offset of the reset set register
- - Offset of the reset status register
-- #reset-cells : Specifies the number of cells needed to encode the
- reset line, should be 2.
- The first cell takes the reset set bit and the
- second cell takes the status bit.
-
--------------------------------------------------------------------------------
-Example for the reset-controllers on the xRX200 SoCs:
- reset0: reset-controller@10 {
- compatible = "lantiq,xrx200-reset";
- reg <0x10 0x04>, <0x14 0x04>;
-
- #reset-cells = <2>;
- };
diff --git a/Documentation/devicetree/bindings/reset/lantiq,reset.yaml b/Documentation/devicetree/bindings/reset/lantiq,reset.yaml
new file mode 100644
index 000000000000..15d65a5dd631
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/lantiq,reset.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/lantiq,reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lantiq XWAY SoC RCU reset controller
+
+maintainers:
+ - Martin Blumenstingl <[email protected]>
+
+description: |
+ This binding describes a reset-controller found on the RCU module on Lantiq
+ XWAY SoCs. This node has to be a sub node of the Lantiq RCU block.
+
+properties:
+ compatible:
+ enum:
+ - lantiq,danube-reset
+ - lantiq,xrx200-reset
+
+ reg:
+ description: |
+ Defines the following sets of registers in the parent syscon device
+ Offset of the reset set register
+ Offset of the reset status register
+ maxItems: 2
+
+ '#reset-cells':
+ description: |
+ The first cell takes the reset set bit and the second cell takes the
+ status bit.
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ // On the xRX200 SoCs:
+ reset0: reset-controller@10 {
+ compatible = "lantiq,xrx200-reset";
+ reg = <0x10 0x04>, <0x14 0x04>;
+ #reset-cells = <2>;
+ };
--
2.30.2
Convert the device tree bindings for the Synopsys HSDK reset controller
to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Eugeniy Paltsev <[email protected]>
---
.../bindings/reset/snps,hsdk-reset.txt | 28 -----------
.../bindings/reset/snps,hsdk-reset.yaml | 47 +++++++++++++++++++
2 files changed, 47 insertions(+), 28 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
deleted file mode 100644
index 830069b1c37c..000000000000
--- a/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Binding for the Synopsys HSDK reset controller
-
-This binding uses the common reset binding[1].
-
-[1] Documentation/devicetree/bindings/reset/reset.txt
-
-Required properties:
-- compatible: should be "snps,hsdk-reset".
-- reg: should always contain 2 pairs address - length: first for reset
- configuration register and second for corresponding SW reset and status bits
- register.
-- #reset-cells: from common reset binding; Should always be set to 1.
-
-Example:
- reset: reset@880 {
- compatible = "snps,hsdk-reset";
- #reset-cells = <1>;
- reg = <0x8A0 0x4>, <0xFF0 0x4>;
- };
-
-Specifying reset lines connected to IP modules:
- ethernet@.... {
- ....
- resets = <&reset HSDK_V1_ETH_RESET>;
- ....
- };
-
-The index could be found in <dt-bindings/reset/snps,hsdk-reset.h>
diff --git a/Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml
new file mode 100644
index 000000000000..a7cb5580c070
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/snps,hsdk-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys HSDK reset controller
+
+maintainers:
+ - Eugeniy Paltsev <[email protected]>
+
+properties:
+ compatible:
+ const: snps,hsdk-reset
+
+ reg:
+ minItems: 2
+ maxItems: 2
+ description: |
+ Should always contain 2 pairs address - length: first for reset
+ configuration register and second for corresponding SW reset and status
+ bits register.
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/snps,hsdk-reset.h>
+
+ reset: reset@880 {
+ compatible = "snps,hsdk-reset";
+ #reset-cells = <1>;
+ reg = <0x8A0 0x4>, <0xFF0 0x4>;
+ };
+
+ // Specifying reset lines connected to IP modules:
+ ethernet {
+ resets = <&reset HSDK_ETH_RESET>;
+ };
--
2.30.2
Convert the device tree bindings for the Nuvoton NPCM reset controller
to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Avi Fishman <[email protected]>
Cc: Tomer Maimon <[email protected]>
Cc: Tali Perry <[email protected]>
Cc: Patrick Venture <[email protected]>
Cc: Nancy Yuen <[email protected]>
Cc: Benjamin Fair <[email protected]>
---
.../bindings/reset/nuvoton,npcm-reset.txt | 32 ------------
.../bindings/reset/nuvoton,npcm750-reset.yaml | 50 +++++++++++++++++++
2 files changed, 50 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt b/Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt
deleted file mode 100644
index 17b7a6a43a29..000000000000
--- a/Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Nuvoton NPCM Reset controller
-
-Required properties:
-- compatible : "nuvoton,npcm750-reset" for NPCM7XX BMC
-- reg : specifies physical base address and size of the register.
-- #reset-cells: must be set to 2
-
-Optional property:
-- nuvoton,sw-reset-number - Contains the software reset number to restart the SoC.
- NPCM7xx contain four software reset that represent numbers 1 to 4.
-
- If 'nuvoton,sw-reset-number' is not specified software reset is disabled.
-
-Example:
- rstc: rstc@f0801000 {
- compatible = "nuvoton,npcm750-reset";
- reg = <0xf0801000 0x70>;
- #reset-cells = <2>;
- nuvoton,sw-reset-number = <2>;
- };
-
-Specifying reset lines connected to IP NPCM7XX modules
-======================================================
-example:
-
- spi0: spi@..... {
- ...
- resets = <&rstc NPCM7XX_RESET_IPSRST2 NPCM7XX_RESET_PSPI1>;
- ...
- };
-
-The index could be found in <dt-bindings/reset/nuvoton,npcm7xx-reset.h>.
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml
new file mode 100644
index 000000000000..fa5e4ea6400e
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/nuvoton,npcm750-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM Reset controller
+
+maintainers:
+ - Tomer Maimon <[email protected]>
+
+properties:
+ compatible:
+ const: nuvoton,npcm750-reset
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 2
+
+ nuvoton,sw-reset-number:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 4
+ description: |
+ Contains the software reset number to restart the SoC.
+ If not specified, software reset is disabled.
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/nuvoton,npcm7xx-reset.h>
+ rstc: rstc@f0801000 {
+ compatible = "nuvoton,npcm750-reset";
+ reg = <0xf0801000 0x70>;
+ #reset-cells = <2>;
+ nuvoton,sw-reset-number = <2>;
+ };
+
+ // Specifying reset lines connected to IP NPCM7XX modules
+ spi0: spi {
+ resets = <&rstc NPCM7XX_RESET_IPSRST2 NPCM7XX_RESET_PSPI1>;
+ };
--
2.30.2
Convert the device tree bindings for the STMicroelectronics STi
SoftReset controller to YAML schema to allow participating in DT
validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Peter Griffin <[email protected]>
---
.../bindings/reset/st,sti-picophyreset.txt | 42 -----------------
.../reset/st,stih407-picophyreset.yaml | 47 +++++++++++++++++++
2 files changed, 47 insertions(+), 42 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/st,sti-picophyreset.txt
create mode 100644 Documentation/devicetree/bindings/reset/st,stih407-picophyreset.yaml
diff --git a/Documentation/devicetree/bindings/reset/st,sti-picophyreset.txt b/Documentation/devicetree/bindings/reset/st,sti-picophyreset.txt
deleted file mode 100644
index 9ca27761f811..000000000000
--- a/Documentation/devicetree/bindings/reset/st,sti-picophyreset.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-STMicroelectronics STi family Sysconfig Picophy SoftReset Controller
-=============================================================================
-
-This binding describes a reset controller device that is used to enable and
-disable on-chip PicoPHY USB2 phy(s) using "softreset" control bits found in
-the STi family SoC system configuration registers.
-
-The actual action taken when softreset is asserted is hardware dependent.
-However, when asserted it may not be possible to access the hardware's
-registers and after an assert/deassert sequence the hardware's previous state
-may no longer be valid.
-
-Please refer to Documentation/devicetree/bindings/reset/reset.txt
-for common reset controller binding usage.
-
-Required properties:
-- compatible: Should be "st,stih407-picophyreset"
-- #reset-cells: 1, see below
-
-Example:
-
- picophyreset: picophyreset-controller {
- compatible = "st,stih407-picophyreset";
- #reset-cells = <1>;
- };
-
-Specifying picophyreset control of devices
-=======================================
-
-Device nodes should specify the reset channel required in their "resets"
-property, containing a phandle to the picophyreset device node and an
-index specifying which channel to use, as described in
-Documentation/devicetree/bindings/reset/reset.txt.
-
-Example:
-
- usb2_picophy0: usbpicophy@0 {
- resets = <&picophyreset STIH407_PICOPHY0_RESET>;
- };
-
-Macro definitions for the supported reset channels can be found in:
-include/dt-bindings/reset/stih407-resets.h
diff --git a/Documentation/devicetree/bindings/reset/st,stih407-picophyreset.yaml b/Documentation/devicetree/bindings/reset/st,stih407-picophyreset.yaml
new file mode 100644
index 000000000000..329ae4ae1a10
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,stih407-picophyreset.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/st,stih407-picophyreset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics STi family Sysconfig Picophy SoftReset Controller
+
+maintainers:
+ - Peter Griffin <[email protected]>
+
+description: |
+ This binding describes a reset controller device that is used to enable and
+ disable on-chip PicoPHY USB2 phy(s) using "softreset" control bits found in
+ the STi family SoC system configuration registers.
+
+ The actual action taken when softreset is asserted is hardware dependent.
+ However, when asserted it may not be possible to access the hardware's
+ registers and after an assert/deassert sequence the hardware's previous state
+ may no longer be valid.
+
+properties:
+ compatible:
+ const: st,stih407-picophyreset
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/reset/stih407-resets.h>
+
+ picophyreset: picophyreset-controller {
+ compatible = "st,stih407-picophyreset";
+ #reset-cells = <1>;
+ };
+
+ // Specifying picophyreset control of devices
+ usb2_picophy0: usbpicophy {
+ resets = <&picophyreset STIH407_PICOPHY0_RESET>;
+ };
--
2.30.2
Convert the device tree bindings for the Oxford Semiconductor OXNAS
reset controllers to YAML schema to allow participating in DT
validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Neil Armstrong <[email protected]>
---
.../devicetree/bindings/reset/oxnas,reset.txt | 32 -------------
.../bindings/reset/oxsemi,oxnas-reset.yaml | 48 +++++++++++++++++++
2 files changed, 48 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/oxnas,reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/oxsemi,oxnas-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/oxnas,reset.txt b/Documentation/devicetree/bindings/reset/oxnas,reset.txt
deleted file mode 100644
index d27ccb5d04fc..000000000000
--- a/Documentation/devicetree/bindings/reset/oxnas,reset.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Oxford Semiconductor OXNAS SoC Family RESET Controller
-================================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-- compatible: For OX810SE, should be "oxsemi,ox810se-reset"
- For OX820, should be "oxsemi,ox820-reset"
-- #reset-cells: 1, see below
-
-Parent node should have the following properties :
-- compatible: For OX810SE, should be :
- "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
- For OX820, should be :
- "oxsemi,ox820-sys-ctrl", "syscon", "simple-mfd"
-
-Reset indices are in dt-bindings include files :
-- For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h
-- For OX820: include/dt-bindings/reset/oxsemi,ox820.h
-
-example:
-
-sys: sys-ctrl@000000 {
- compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd";
- reg = <0x000000 0x100000>;
-
- reset: reset-controller {
- compatible = "oxsemi,ox810se-reset";
- #reset-cells = <1>;
- };
-};
diff --git a/Documentation/devicetree/bindings/reset/oxsemi,oxnas-reset.yaml b/Documentation/devicetree/bindings/reset/oxsemi,oxnas-reset.yaml
new file mode 100644
index 000000000000..3cd2ce85a056
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/oxsemi,oxnas-reset.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/oxsemi,oxnas-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Oxford Semiconductor OXNAS SoC Family RESET Controller
+
+maintainers:
+ - Neil Armstrong <[email protected]>
+
+description: |
+ Reset indices are in dt bindings include files:
+ - For OX810SE: include/dt-bindings/reset/oxsemi,ox810se.h
+ - For OX820: include/dt-bindings/reset/oxsemi,ox820.h
+
+properties:
+ compatible:
+ enum:
+ - oxsemi,ox810se-reset
+ - oxsemi,ox820-reset
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ // For OX810SE:
+ #include <dt-bindings/reset/oxsemi,ox810se.h>
+
+ sys: sys-ctrl@000000 {
+ compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd";
+ reg = <0x000000 0x100000>;
+
+ reset: reset-controller {
+ compatible = "oxsemi,ox810se-reset";
+ #reset-cells = <1>;
+ };
+ };
--
2.30.2
Convert the device tree bindings for the Synopsys DesignWare reset
controller to YAML schema to allow participating in DT validation.
Signed-off-by: Philipp Zabel <[email protected]>
Cc: Luis Oliveira <[email protected]>
---
.../bindings/reset/snps,dw-reset.txt | 30 -------------
.../bindings/reset/snps,dw-reset.yaml | 44 +++++++++++++++++++
2 files changed, 44 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
deleted file mode 100644
index 0c241d4aae76..000000000000
--- a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Synopsys DesignWare Reset controller
-=======================================
-
-Please also refer to reset.txt in this directory for common reset
-controller binding usage.
-
-Required properties:
-
-- compatible: should be one of the following.
- "snps,dw-high-reset" - for active high configuration
- "snps,dw-low-reset" - for active low configuration
-
-- reg: physical base address of the controller and length of memory mapped
- region.
-
-- #reset-cells: must be 1.
-
-example:
-
- dw_rst_1: reset-controller@0000 {
- compatible = "snps,dw-high-reset";
- reg = <0x0000 0x4>;
- #reset-cells = <1>;
- };
-
- dw_rst_2: reset-controller@1000 {
- compatible = "snps,dw-low-reset";
- reg = <0x1000 0x8>;
- #reset-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
new file mode 100644
index 000000000000..f9b36ddc0ea1
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/snps,dw-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare Reset controller
+
+maintainers:
+ - Luis Oliveira <[email protected]>
+
+properties:
+ compatible:
+ enum:
+ - snps,dw-high-reset # for active high configuration
+ - snps,dw-low-reset # for active low configuration
+
+ reg:
+ maxItems: 1
+
+ '#reset-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ dw_rst_1: reset-controller@0000 {
+ compatible = "snps,dw-high-reset";
+ reg = <0x0000 0x4>;
+ #reset-cells = <1>;
+ };
+
+ dw_rst_2: reset-controller@1000 {
+ compatible = "snps,dw-low-reset";
+ reg = <0x1000 0x8>;
+ #reset-cells = <1>;
+ };
+
--
2.30.2
On Thu, Apr 07, 2022 at 05:43:38PM +0200, Philipp Zabel wrote:
> Convert the common reset controller and reset consumer device tree
> bindings to YAML schema.
In general, common bindings should go in DT schema repo:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reset/reset.yaml
Though part of the issue is dtschema is dual licensed and all the
exsting text is GPL2, so permission to relicense is needed. That's why
the schemas are just the schema and little description ATM. Shouldn't
be too hard here with Stephen/NVIDIA being the only copyright holder.
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Stephen Warren <[email protected]>
> ---
> .../bindings/reset/reset-consumer.yaml | 72 ++++++++++++++++++
> .../bindings/reset/reset-controller.yaml | 50 +++++++++++++
> .../devicetree/bindings/reset/reset.txt | 75 -------------------
> 3 files changed, 122 insertions(+), 75 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/reset/reset-consumer.yaml
> create mode 100644 Documentation/devicetree/bindings/reset/reset-controller.yaml
> delete mode 100644 Documentation/devicetree/bindings/reset/reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/reset-consumer.yaml b/Documentation/devicetree/bindings/reset/reset-consumer.yaml
> new file mode 100644
> index 000000000000..e17229eb49c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/reset-consumer.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright 2012 Stephen Warren <[email protected]>
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/reset-consumer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common reset signal consumer bindings
> +
> +maintainers:
> + - Philipp Zabel <[email protected]>
> +
> +description: |
> + Hardware blocks typically receive a reset signal. This signal is generated by
> + a reset provider (e.g. power management or clock module) and received by a
> + reset consumer (the module being reset, or a module managing when a sub-
> + ordinate module is reset). This binding exists to represent the consumers of
> + reset signals provided by reset controllers.
> +
> + A reset signal is represented by the phandle of the provider, plus a reset
> + specifier - a list of DT cells that represents the reset signal within the
> + provider. The length (number of cells) and semantics of the reset specifier
> + are dictated by the binding of the reset provider, although common schemes
> + are described below.
> +
> + A word on where to place reset signal consumers in device tree: It is possible
> + in hardware for a reset signal to affect multiple logically separate HW blocks
> + at once. In this case, it would be unwise to represent this reset signal in
> + the DT node of each affected HW block, since if activated, an unrelated block
> + may be reset. Instead, reset signals should be represented in the DT node
> + where it makes most sense to control it; this may be a bus node if all
> + children of the bus are affected by the reset signal, or an individual HW
> + block node for dedicated reset signals. The intent of this binding is to give
> + appropriate software access to the reset signals in order to manage the HW,
> + rather than to slavishly enumerate the reset signal that affects each HW
> + block.
> +
> +select: true
> +
> +properties:
> + resets:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: |
> + List of phandle and reset specifier pairs, one pair for each reset signal
> + that affects the device, or that the device manages.
> + Note: if the reset provider specifies '0' for "#reset-cells", then only
> + the phandle portion of the pair will appear.
> +
> + reset-names:
> + description: |
> + List of reset signal name strings sorted in the same order as the resets
> + property. Consumers drivers will use "reset-names" to match reset signal
> + names with reset specifiers.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + // A device with a single reset signal named "reset".
> + device {
> + resets = <&rst 20>;
> + reset-names = "reset";
> + };
> + - |
> + // A bus that controls the reset signal of each of four subordinate
> + // devices. Consider for example a bus that fails to operate unless no
> + // child device has reset asserted.
> + bus {
> + resets = <&rst 10>, <&rst 11>, <&rst 12>, <&rst 11>;
> + reset-names = "i2s1", "i2s2", "dma", "mixer";
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/reset/reset-controller.yaml b/Documentation/devicetree/bindings/reset/reset-controller.yaml
> new file mode 100644
> index 000000000000..33468f94f4c2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/reset-controller.yaml
> @@ -0,0 +1,50 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright 2021 Stephen Warren <[email protected]>
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/reset-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common reset controller provider bindings
> +
> +maintainers:
> + - Philipp Zabel <[email protected]>
> +
> +description: |
> + This binding is intended to represent the hardware reset signals present
> + internally in most IC (SoC, FPGA, ...) designs. Reset signals for whole
> + standalone chips are most likely better represented as GPIOs, although there
> + are likely to be exceptions to this rule.
> +
> + Hardware blocks typically receive a reset signal. This signal is generated by
> + a reset provider (e.g. power management or clock module) and received by a
> + reset consumer (the module being reset, or a module managing when a sub-
> + ordinate module is reset). This binding exists to represent the provider of
> + one or more reset signals.
> +
> +select:
> + anyOf:
> + - properties:
> + $nodename:
> + pattern: '^reset-controller'
This actually serves no purpose unless you made #reset-cells required.
If the node name matches, the schema will be applied and be true whether
#reset-cells is present or not.
We were trying to define the node name for providers, but that breaks in
cases of nodes that are multiple providers which as you know is common
in this case. So we need to come up with another way of encouraging
standard node names.
> + - required:
> + - '#reset-cells'
> +
> +properties:
> + '#reset-cells':
> + $ref: /schemas/types.yaml#/definitions/uint32
'#.*-cells' has a type already. The only thing you can really put here
would be some constraint on the range of number of cells allowed and a
description.
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> + // A reset controller providing multiple reset controls
> + rst: reset-controller {
> + #reset-cells = <1>;
> + };
> +
> + // A reset consumer receiving a single reset signal with index 0
> + peripheral {
> + resets = <&rst 0>;
> + };
> +...
On Thu, 07 Apr 2022 17:43:28 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Bitmain BM1880 reset controller
> to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Manivannan Sadhasivam <[email protected]>
> ---
> .../bindings/reset/bitmain,bm1880-reset.txt | 18 ----------
> .../bindings/reset/bitmain,bm1880-reset.yaml | 36 +++++++++++++++++++
> 2 files changed, 36 insertions(+), 18 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.yaml
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, 07 Apr 2022 17:43:35 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Altera SOCFPGA reset manager to
> YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Dinh Nguyen <[email protected]>
> ---
> .../bindings/reset/altr,rst-mgr.yaml | 47 +++++++++++++++++++
> .../bindings/reset/socfpga-reset.txt | 16 -------
> 2 files changed, 47 insertions(+), 16 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/reset/altr,rst-mgr.yaml
> delete mode 100644 Documentation/devicetree/bindings/reset/socfpga-reset.txt
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, 07 Apr 2022 17:43:25 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Amlogic audio memory arbiter
> controller to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Kevin Hilman <[email protected]>
> Cc: Jerome Brunet <[email protected]>
> Cc: Martin Blumenstingl <[email protected]>
> ---
> .../reset/amlogic,meson-axg-audio-arb.txt | 22 --------
> .../reset/amlogic,meson-axg-audio-arb.yaml | 56 +++++++++++++++++++
> 2 files changed, 56 insertions(+), 22 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.txt
> create mode 100644 Documentation/devicetree/bindings/reset/amlogic,meson-axg-audio-arb.yaml
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, 07 Apr 2022 17:43:26 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Qualcomm Atheros AR7xxx/AR9XXX
> reset controller to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Alban Bedel <[email protected]>
> ---
> .../devicetree/bindings/reset/ath79-reset.txt | 20 ----------
> .../bindings/reset/qca,ar7100-reset.yaml | 40 +++++++++++++++++++
> 2 files changed, 40 insertions(+), 20 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/ath79-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/qca,ar7100-reset.yaml
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, 07 Apr 2022 17:43:33 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Synopsys DesignWare reset
> controller to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Luis Oliveira <[email protected]>
> ---
> .../bindings/reset/snps,dw-reset.txt | 30 -------------
> .../bindings/reset/snps,dw-reset.yaml | 44 +++++++++++++++++++
> 2 files changed, 44 insertions(+), 30 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/reset/snps,dw-reset.example.dts:20.41-24.11: Warning (unit_address_format): /example-0/reset-controller@0000: unit name should not have leading 0s
doc reference errors (make refcheckdocs):
Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt
MAINTAINERS: Documentation/devicetree/bindings/reset/snps,axs10x-reset.txt
See https://patchwork.ozlabs.org/patch/
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
On Thu, Apr 07, 2022 at 05:43:33PM +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Synopsys DesignWare reset
> controller to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Luis Oliveira <[email protected]>
> ---
> .../bindings/reset/snps,dw-reset.txt | 30 -------------
> .../bindings/reset/snps,dw-reset.yaml | 44 +++++++++++++++++++
> 2 files changed, 44 insertions(+), 30 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
>
> diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> deleted file mode 100644
> index 0c241d4aae76..000000000000
> --- a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -Synopsys DesignWare Reset controller
> -=======================================
> -
> -Please also refer to reset.txt in this directory for common reset
> -controller binding usage.
> -
> -Required properties:
> -
> -- compatible: should be one of the following.
> - "snps,dw-high-reset" - for active high configuration
> - "snps,dw-low-reset" - for active low configuration
> -
> -- reg: physical base address of the controller and length of memory mapped
> - region.
> -
> -- #reset-cells: must be 1.
> -
> -example:
> -
> - dw_rst_1: reset-controller@0000 {
> - compatible = "snps,dw-high-reset";
> - reg = <0x0000 0x4>;
> - #reset-cells = <1>;
> - };
> -
> - dw_rst_2: reset-controller@1000 {
> - compatible = "snps,dw-low-reset";
> - reg = <0x1000 0x8>;
> - #reset-cells = <1>;
> - };
> diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
> new file mode 100644
> index 000000000000..f9b36ddc0ea1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/snps,dw-reset.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare Reset controller
> +
> +maintainers:
> + - Luis Oliveira <[email protected]>
Mail bounces, needs a new one.
> +
> +properties:
> + compatible:
> + enum:
> + - snps,dw-high-reset # for active high configuration
> + - snps,dw-low-reset # for active low configuration
> +
> + reg:
> + maxItems: 1
> +
> + '#reset-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - '#reset-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + dw_rst_1: reset-controller@0000 {
> + compatible = "snps,dw-high-reset";
> + reg = <0x0000 0x4>;
> + #reset-cells = <1>;
> + };
> +
> + dw_rst_2: reset-controller@1000 {
> + compatible = "snps,dw-low-reset";
> + reg = <0x1000 0x8>;
> + #reset-cells = <1>;
> + };
> +
> --
> 2.30.2
>
>
On Thu, 07 Apr 2022 17:43:31 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Oxford Semiconductor OXNAS
> reset controllers to YAML schema to allow participating in DT
> validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Neil Armstrong <[email protected]>
> ---
> .../devicetree/bindings/reset/oxnas,reset.txt | 32 -------------
> .../bindings/reset/oxsemi,oxnas-reset.yaml | 48 +++++++++++++++++++
> 2 files changed, 48 insertions(+), 32 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/oxnas,reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/oxsemi,oxnas-reset.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/reset/oxsemi,oxnas-reset.example.dts:23.30-31.11: Warning (unit_address_format): /example-0/sys-ctrl@000000: unit name should not have leading 0s
Documentation/devicetree/bindings/reset/oxsemi,oxnas-reset.example.dtb:0:0: /example-0/sys-ctrl@000000: failed to match any schema with compatible: ['oxsemi,ox810se-sys-ctrl', 'syscon', 'simple-mfd']
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
On Thu, 07 Apr 2022 17:43:29 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Lantiq XWAY SoC RCU reset
> controller to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Martin Blumenstingl <[email protected]>
> ---
> .../bindings/reset/lantiq,reset.txt | 30 ------------
> .../bindings/reset/lantiq,reset.yaml | 49 +++++++++++++++++++
> 2 files changed, 49 insertions(+), 30 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/lantiq,reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/lantiq,reset.yaml
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, 07 Apr 2022 17:43:30 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Nuvoton NPCM reset controller
> to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Avi Fishman <[email protected]>
> Cc: Tomer Maimon <[email protected]>
> Cc: Tali Perry <[email protected]>
> Cc: Patrick Venture <[email protected]>
> Cc: Nancy Yuen <[email protected]>
> Cc: Benjamin Fair <[email protected]>
> ---
> .../bindings/reset/nuvoton,npcm-reset.txt | 32 ------------
> .../bindings/reset/nuvoton,npcm750-reset.yaml | 50 +++++++++++++++++++
> 2 files changed, 50 insertions(+), 32 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/nuvoton,npcm-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/nuvoton,npcm750-reset.yaml
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, Apr 07, 2022 at 05:43:34PM +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Synopsys HSDK reset controller
> to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Eugeniy Paltsev <[email protected]>
> ---
> .../bindings/reset/snps,hsdk-reset.txt | 28 -----------
> .../bindings/reset/snps,hsdk-reset.yaml | 47 +++++++++++++++++++
> 2 files changed, 47 insertions(+), 28 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml
>
> diff --git a/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
> deleted file mode 100644
> index 830069b1c37c..000000000000
> --- a/Documentation/devicetree/bindings/reset/snps,hsdk-reset.txt
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -Binding for the Synopsys HSDK reset controller
> -
> -This binding uses the common reset binding[1].
> -
> -[1] Documentation/devicetree/bindings/reset/reset.txt
> -
> -Required properties:
> -- compatible: should be "snps,hsdk-reset".
> -- reg: should always contain 2 pairs address - length: first for reset
> - configuration register and second for corresponding SW reset and status bits
> - register.
> -- #reset-cells: from common reset binding; Should always be set to 1.
> -
> -Example:
> - reset: reset@880 {
> - compatible = "snps,hsdk-reset";
> - #reset-cells = <1>;
> - reg = <0x8A0 0x4>, <0xFF0 0x4>;
> - };
> -
> -Specifying reset lines connected to IP modules:
> - ethernet@.... {
> - ....
> - resets = <&reset HSDK_V1_ETH_RESET>;
> - ....
> - };
> -
> -The index could be found in <dt-bindings/reset/snps,hsdk-reset.h>
> diff --git a/Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml
> new file mode 100644
> index 000000000000..a7cb5580c070
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/snps,hsdk-reset.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/snps,hsdk-reset.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys HSDK reset controller
> +
> +maintainers:
> + - Eugeniy Paltsev <[email protected]>
> +
> +properties:
> + compatible:
> + const: snps,hsdk-reset
> +
> + reg:
> + minItems: 2
> + maxItems: 2
> + description: |
> + Should always contain 2 pairs address - length: first for reset
> + configuration register and second for corresponding SW reset and status
> + bits register.
items:
- description: reset configuration register
- description: corresponding SW reset and status bits register
> +
> + '#reset-cells':
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - '#reset-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/reset/snps,hsdk-reset.h>
> +
> + reset: reset@880 {
> + compatible = "snps,hsdk-reset";
> + #reset-cells = <1>;
> + reg = <0x8A0 0x4>, <0xFF0 0x4>;
> + };
> +
> + // Specifying reset lines connected to IP modules:
> + ethernet {
> + resets = <&reset HSDK_ETH_RESET>;
> + };
No need to show the consumer side in every provider. Please drop.
Rob
On Fr, 2022-04-08 at 13:25 -0500, Rob Herring wrote:
> On Thu, Apr 07, 2022 at 05:43:33PM +0200, Philipp Zabel wrote:
> > Convert the device tree bindings for the Synopsys DesignWare reset
> > controller to YAML schema to allow participating in DT validation.
> >
> > Signed-off-by: Philipp Zabel <[email protected]>
> > Cc: Luis Oliveira <[email protected]>
Cc: Gustavo Pimentel <[email protected]>
> > ---
> > .../bindings/reset/snps,dw-reset.txt | 30 -------------
> > .../bindings/reset/snps,dw-reset.yaml | 44 +++++++++++++++++++
> > 2 files changed, 44 insertions(+), 30 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> > create mode 100644 Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt b/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> > deleted file mode 100644
> > index 0c241d4aae76..000000000000
> > --- a/Documentation/devicetree/bindings/reset/snps,dw-reset.txt
> > +++ /dev/null
> > @@ -1,30 +0,0 @@
> > -Synopsys DesignWare Reset controller
> > -=======================================
> > -
> > -Please also refer to reset.txt in this directory for common reset
> > -controller binding usage.
> > -
> > -Required properties:
> > -
> > -- compatible: should be one of the following.
> > - "snps,dw-high-reset" - for active high configuration
> > - "snps,dw-low-reset" - for active low configuration
> > -
> > -- reg: physical base address of the controller and length of memory mapped
> > - region.
> > -
> > -- #reset-cells: must be 1.
> > -
> > -example:
> > -
> > - dw_rst_1: reset-controller@0000 {
> > - compatible = "snps,dw-high-reset";
> > - reg = <0x0000 0x4>;
> > - #reset-cells = <1>;
> > - };
> > -
> > - dw_rst_2: reset-controller@1000 {
> > - compatible = "snps,dw-low-reset";
> > - reg = <0x1000 0x8>;
> > - #reset-cells = <1>;
> > - };
> > diff --git a/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
> > new file mode 100644
> > index 000000000000..f9b36ddc0ea1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/reset/snps,dw-reset.yaml
> > @@ -0,0 +1,44 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/reset/snps,dw-reset.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Synopsys DesignWare Reset controller
> > +
> > +maintainers:
> > + - Luis Oliveira <[email protected]>
>
> Mail bounces, needs a new one.
Gustavo, would you take on maintainership of this file?
regards
Philipp
On Thu, 07 Apr 2022 17:43:36 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the STMicroelectronics STi
> SoftReset controller to YAML schema to allow participating in DT
> validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Peter Griffin <[email protected]>
> ---
> .../bindings/reset/st,sti-picophyreset.txt | 42 -----------------
> .../reset/st,stih407-picophyreset.yaml | 47 +++++++++++++++++++
> 2 files changed, 47 insertions(+), 42 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/st,sti-picophyreset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/st,stih407-picophyreset.yaml
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, 07 Apr 2022 17:43:27 +0200, Philipp Zabel wrote:
> Convert the device tree bindings for the Marvell Berlin reset controller
> to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Antoine Tenart <[email protected]>
> ---
> .../bindings/reset/berlin,reset.txt | 23 -----------
> .../bindings/reset/marvell,berlin2-reset.yaml | 38 +++++++++++++++++++
> 2 files changed, 38 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/berlin,reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/marvell,berlin2-reset.yaml
>
Reviewed-by: Rob Herring <[email protected]>
On Thu, Apr 7, 2022 at 5:44 PM Philipp Zabel <[email protected]> wrote:
>
> Convert the device tree bindings for the Amlogic audio memory arbiter
> controller to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Kevin Hilman <[email protected]>
> Cc: Jerome Brunet <[email protected]>
> Cc: Martin Blumenstingl <[email protected]>
Reviewed-by: Martin Blumenstingl <[email protected]>
On Thu, Apr 7, 2022 at 5:44 PM Philipp Zabel <[email protected]> wrote:
>
> Convert the device tree bindings for the Lantiq XWAY SoC RCU reset
> controller to YAML schema to allow participating in DT validation.
>
> Signed-off-by: Philipp Zabel <[email protected]>
> Cc: Martin Blumenstingl <[email protected]>
Reviewed-by: Martin Blumenstingl <[email protected]>
I am not sure who can take this patch (through which tree).
Maybe Rob can simply take it through his devicetree tree?
Best regards,
Martin
On Mo, 2022-04-18 at 18:34 +0200, Martin Blumenstingl wrote:
> On Thu, Apr 7, 2022 at 5:44 PM Philipp Zabel <[email protected]> wrote:
> >
> > Convert the device tree bindings for the Lantiq XWAY SoC RCU reset
> > controller to YAML schema to allow participating in DT validation.
> >
> > Signed-off-by: Philipp Zabel <[email protected]>
> > Cc: Martin Blumenstingl <[email protected]>
> Reviewed-by: Martin Blumenstingl <[email protected]>
>
> I am not sure who can take this patch (through which tree).
> Maybe Rob can simply take it through his devicetree tree?
Thank you, I have just picked up all reviewed patches into the reset
tree.
regards
Philipp
Rob Herring <[email protected]> wrote at Thursday, April 7, 2022 2:04 PM:
> On Thu, Apr 07, 2022 at 05:43:38PM +0200, Philipp Zabel wrote:
> > Convert the common reset controller and reset consumer device tree
> > bindings to YAML schema.
>
> In general, common bindings should go in DT schema repo:
>
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reset/reset.yaml
>
> Though part of the issue is dtschema is dual licensed and all the
> exsting text is GPL2, so permission to relicense is needed. That's why
> the schemas are just the schema and little description ATM. Shouldn't
> be too hard here with Stephen/NVIDIA being the only copyright holder.
All the work I did for NVIDIA should be (c) NVIDIA, i.e.:
# Copyright (c) 2012, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
I have checked with NVIDIA legal etc, and NVIDIA gives permission to
relicense any file they hold copyright on within the
Documentation/devicetree/bindings directory of the Linux kernel source
tree to MIT-only, e.g. for inclusion into the new dtschema repository.
Separately, I give permission for the same; some of the files I
added/edited in that directory were part of my job (generally Tegra
related) and so covered by NVIDIA copyright, whereas others were part of
personal work (generally Raspberry-Pi related).
My apologies if Outlook/Exchange mangle this email.
--
nvpublic
On Wed, May 4, 2022 at 8:08 PM Stephen Warren <[email protected]> wrote:
>
> Rob Herring <[email protected]> wrote at Thursday, April 7, 2022 2:04 PM:
> > On Thu, Apr 07, 2022 at 05:43:38PM +0200, Philipp Zabel wrote:
> > > Convert the common reset controller and reset consumer device tree
> > > bindings to YAML schema.
> >
> > In general, common bindings should go in DT schema repo:
> >
> > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reset/reset.yaml
> >
> > Though part of the issue is dtschema is dual licensed and all the
> > exsting text is GPL2, so permission to relicense is needed. That's why
> > the schemas are just the schema and little description ATM. Shouldn't
> > be too hard here with Stephen/NVIDIA being the only copyright holder.
>
> All the work I did for NVIDIA should be (c) NVIDIA, i.e.:
>
> # Copyright (c) 2012, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
>
> I have checked with NVIDIA legal etc, and NVIDIA gives permission to
> relicense any file they hold copyright on within the
> Documentation/devicetree/bindings directory of the Linux kernel source
> tree to MIT-only, e.g. for inclusion into the new dtschema repository.
Great! However, the license for dtschema is BSD-2-Clause. Is BSD okay?
While MIT is similar and compatible, I'd prefer not to have a
proliferation of different licenses simply because people don't pay
attention when copying things.
There's another header relicensing now[1], gpio.h, which NVIDIA contributed to.
Rob
[1] https://lore.kernel.org/all/[email protected]/
Rob Herring wrote at Thursday, August 25, 2022 9:53 AM:
> On Wed, May 4, 2022 at 8:08 PM Stephen Warren <[email protected]> wrote:
> >
> > Rob Herring <[email protected]> wrote at Thursday, April 7, 2022 2:04 PM:
> > > On Thu, Apr 07, 2022 at 05:43:38PM +0200, Philipp Zabel wrote:
> > > > Convert the common reset controller and reset consumer device tree
> > > > bindings to YAML schema.
> > >
> > > In general, common bindings should go in DT schema repo:
> > >
> > > https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reset/reset.yaml
> > >
> > > Though part of the issue is dtschema is dual licensed and all the
> > > exsting text is GPL2, so permission to relicense is needed. That's why
> > > the schemas are just the schema and little description ATM. Shouldn't
> > > be too hard here with Stephen/NVIDIA being the only copyright holder.
> >
> > All the work I did for NVIDIA should be (c) NVIDIA, i.e.:
> >
> > # Copyright (c) 2012, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
> >
> > I have checked with NVIDIA legal etc, and NVIDIA gives permission to
> > relicense any file they hold copyright on within the
> > Documentation/devicetree/bindings directory of the Linux kernel source
> > tree to MIT-only, e.g. for inclusion into the new dtschema repository.
>
> Great! However, the license for dtschema is BSD-2-Clause. Is BSD okay?
> While MIT is similar and compatible, I'd prefer not to have a
> proliferation of different licenses simply because people don't pay
> attention when copying things.
Based on legal's prior response, they are not fixated upon MIT license, so the
BSD-2-Clause license would be fine too; they indicated that even "public domain"
would be fine, except that they don't have a boilerplate header for that, and it's
not suitable since not recognized everywhere, so weren't going to actually
recommend that.
I asked legal about arbitrary files in include/dt-bindings/ in the Linux kernel tree,
so I believe their response is a blanket one for all such files, including [1] below.
For any future similar issues, then Thierry Reding or Jonathan Hunter (both CC'd)
are the people to follow up with. For their context, they can see nvbug 2426449.
> There's another header relicensing now[1], gpio.h, which NVIDIA contributed to.
>
> Rob
>
> [1] https://lore.kernel.org/all/[email protected]/
(My apologies if Outlook mangles this message or interferes with the mailing list...)
--
nvpublic