[PATCH] dt-bindings: power: reset: ti,keystone-reset: Convert to DT schema

[PATCH] dt-bindings: power: reset: ti,keystone-reset: Convert to DT schema

[Bhargav Joshi]

Convert Texas Instruments Keystone SoC Reset Controller from text to DT
schema. no new functional changes.

Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
 .../bindings/power/reset/keystone-reset.txt        | 67 ------------------
 .../bindings/power/reset/ti,keystone-reset.yaml    | 81 ++++++++++++++++++++++
 2 files changed, 81 insertions(+), 67 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
deleted file mode 100644
index c5c03789ed1e..000000000000
--- a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Device tree bindings for Texas Instruments keystone reset
-
-This node is intended to allow SoC reset in case of software reset
-of selected watchdogs.
-
-The Keystone SoCs can contain up to 4 watchdog timers to reset
-SoC. Each watchdog timer event input is connected to the Reset Mux
-block. The Reset Mux block can be configured to cause reset or not.
-
-Additionally soft or hard reset can be configured.
-
-Required properties:
-
-- compatible:		ti,keystone-reset
-
-- ti,syscon-pll:	phandle/offset pair. The phandle to syscon used to
-			access pll controller registers and the offset to use
-			reset control registers.
-
-- ti,syscon-dev:	phandle/offset pair. The phandle to syscon used to
-			access device state control registers and the offset
-			in order to use mux block registers for all watchdogs.
-
-Optional properties:
-
-- ti,soft-reset:	Boolean option indicating soft reset.
-			By default hard reset is used.
-
-- ti,wdt-list:		WDT list that can cause SoC reset. It's not related
-			to WDT driver, it's just needed to enable a SoC related
-			reset that's triggered by one of WDTs. The list is
-			in format: <0>, <2>; It can be in random order and
-			begins from 0 to 3, as keystone can contain up to 4 SoC
-			reset watchdogs and can be in random order.
-
-Example 1:
-Setup keystone reset so that in case software reset or
-WDT0 is triggered it issues hard reset for SoC.
-
-pllctrl: pll-controller@2310000 {
-	compatible = "ti,keystone-pllctrl", "syscon";
-	reg = <0x02310000 0x200>;
-};
-
-devctrl: device-state-control@2620000 {
-	compatible = "ti,keystone-devctrl", "syscon";
-	reg = <0x02620000 0x1000>;
-};
-
-rstctrl: reset-controller {
-	compatible = "ti,keystone-reset";
-	ti,syscon-pll = <&pllctrl 0xe4>;
-	ti,syscon-dev = <&devctrl 0x328>;
-	ti,wdt-list = <0>;
-};
-
-Example 2:
-Setup keystone reset so that in case of software reset or
-WDT0 or WDT2 is triggered it issues soft reset for SoC.
-
-rstctrl: reset-controller {
-	compatible = "ti,keystone-reset";
-	ti,syscon-pll = <&pllctrl 0xe4>;
-	ti,syscon-dev = <&devctrl 0x328>;
-	ti,wdt-list = <0>, <2>;
-	ti,soft-reset;
-};
diff --git a/Documentation/devicetree/bindings/power/reset/ti,keystone-reset.yaml b/Documentation/devicetree/bindings/power/reset/ti,keystone-reset.yaml
new file mode 100644
index 000000000000..ecc68d37f07e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/ti,keystone-reset.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/reset/ti,keystone-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Keystone SoC Reset Controller
+
+maintainers:
+  - Andrew Davis <afd@ti.com>
+
+description:
+  This is intended to allow SoC reset in case of software reset of selected
+  watchdogs. The Keystone SoCs can contain up to 4 watchdog timers to reset
+  SoC. Each watchdog timer event input is connected to the Reset Mux block. The
+  Reset Mux block can be configured to cause reset or not. Additionally soft or
+  hard reset can be configured.
+
+properties:
+  compatible:
+    const: ti,keystone-reset
+
+  reg:
+    maxItems: 1
+
+  ti,syscon-pll:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description:
+      The phandle to syscon used to access pll controller registers and the
+      offset to use reset control registers.
+    items:
+      - items:
+          - description: phandle to pll controller syscon
+          - description: offset within pll controller register space
+
+  ti,syscon-dev:
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    description:
+      The phandle to syscon used to access device state control registers and
+      the offset in order to use mux block registers for all watchdogs.
+    items:
+      - items:
+          - description: phandle to device state control syscon
+          - description: offset within device state control register
+
+  ti,soft-reset:
+    type: boolean
+    description:
+      Boolean option indicating soft reset. By default hard reset is used.
+
+  ti,wdt-list:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      WDT list that can cause SoC reset. It's not related to WDT driver, it's
+      just needed to enable a SoC related reset that's triggered by one of
+      WDTs. The list is in format- <0>, <2>; It can be in random order and
+      begins from 0 to 3, as keystone can contain up to 4 SoC reset watchdogs
+      and can be in random order.
+    minItems: 1
+    maxItems: 4
+    items:
+      minimum: 0
+      maximum: 3
+
+required:
+  - compatible
+  - reg
+  - ti,syscon-pll
+  - ti,syscon-dev
+
+additionalProperties: false
+
+examples:
+  - |
+    reset-controller@328 {
+        compatible = "ti,keystone-reset";
+        reg = <0x328 0x10>;
+        ti,syscon-pll = <&pllctrl 0xe4>;
+        ti,syscon-dev = <&devctrl 0x328>;
+        ti,wdt-list = <0>;
+    };

---
base-commit: 3d6d817622b0a9721e3cc404df3469171582be13
change-id: 20260813-ti-keystone-reset-9ab2c8381651

Best regards,
-- 
Bhargav

Re: [PATCH] dt-bindings: power: reset: ti,keystone-reset: Convert to DT schema

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The 'reg' property is newly marked as strictly required in the schema, which breaks backward compatibility with existing out-of-tree device trees.
--

--- Patch [1]: [PATCH] dt-bindings: power: reset: ti,keystone-reset: Convert to DT schema ---
commit 63d9431256b9847ef3ca6d5aacac09610df2a267
Author: Bhargav Joshi <j.bhargav.u@gmail.com>

dt-bindings: power: reset: ti,keystone-reset: Convert to DT schema

This commit converts the Texas Instruments Keystone SoC Reset Controller
binding from a text document to a DT schema. The commit message notes
there are no new functional changes.

> diff --git a/Documentation/devicetree/bindings/power/reset/ti,keystone-reset.yaml b/Documentation/devicetree/bindings/power/reset/ti,keystone-reset.yaml
> new file mode 100644
> index 0000000000000..ecc68d37f07e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/ti,keystone-reset.yaml

[ ... ]

> +required:
> +  - compatible
> +  - reg

[Severity: Medium]
Does adding 'reg' to the required list break backward compatibility with
existing device trees?

The old text binding did not document or include a 'reg' property in its
examples, meaning existing device trees following the old binding will now
fail validation during `make dtbs_check` with this new schema. Since the
kernel driver does not parse or map the 'reg' property and relies on syscon
offsets instead, is it necessary to mark 'reg' as strictly required here?

> +  - ti,syscon-pll
> +  - ti,syscon-dev
> +
> +additionalProperties: false

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813-ti-keystone-reset-v1-1-189389503324@gmail.com?part=1