Hi,
I understand that the following series belong to various maintainers,
but, it is a bit better reviewed as a single series for
cohesiveness.
There are also dts fixups that this series exposes, which is good, but
I chose to hold them back for now pending binding review at least. The
complete series is available in [1] if folks are curious.
Nishanth Menon (4):
dt-bindings: reset: Convert ti,sci-reset to json schema
dt-bindings: clock: Convert ti,sci-clk to json schema
dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
dt-bindings: arm: keystone: Convert ti,sci to json schema
.../bindings/arm/keystone/ti,sci.txt | 86 ------------
.../bindings/arm/keystone/ti,sci.yaml | 129 ++++++++++++++++++
.../devicetree/bindings/clock/ti,sci-clk.txt | 36 -----
.../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++++++
.../bindings/reset/ti,sci-reset.txt | 62 ---------
.../bindings/reset/ti,sci-reset.yaml | 51 +++++++
.../bindings/soc/ti/sci-pm-domain.txt | 65 ---------
.../bindings/soc/ti/sci-pm-domain.yaml | 59 ++++++++
8 files changed, 291 insertions(+), 249 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
[1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci
Regards,
Nishanth Menon
--
2.31.0
Convert the ti,sci-clk to json schema for better checks and documentation.
Differences being:
- Drop consumer example as they are documented in the corresponding
bindings themselves.
- Standardize the node name as clock-controller rather than clocks as
it is more appropriate.
- Drop phandle description for clock-cells as it is redundant.
NOTE: we do have false positive checkpatch warning with this patch:
"DT binding docs and includes should be a separate patch"
Signed-off-by: Nishanth Menon <[email protected]>
---
.../devicetree/bindings/clock/ti,sci-clk.txt | 36 -------------
.../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++++++++++++++++++
2 files changed, 52 insertions(+), 36 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
deleted file mode 100644
index 4e59dc6b1778..000000000000
--- a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Texas Instruments TI-SCI Clocks
-===============================
-
-All clocks on Texas Instruments' SoCs that contain a System Controller,
-are only controlled by this entity. Communication between a host processor
-running an OS and the System Controller happens through a protocol known
-as TI-SCI[1]. This clock implementation plugs into the common clock
-framework and makes use of the TI-SCI protocol on clock API requests.
-
-[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-Required properties:
--------------------
-- compatible: Must be "ti,k2g-sci-clk"
-- #clock-cells: Shall be 2.
- In clock consumers, this cell represents the device ID and clock ID
- exposed by the PM firmware. The list of valid values for the device IDs
- and clocks IDs for 66AK2G SoC are documented at
- http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
-
-Examples:
---------
-
-pmmc: pmmc {
- compatible = "ti,k2g-sci";
-
- k2g_clks: clocks {
- compatible = "ti,k2g-sci-clk";
- #clock-cells = <2>;
- };
-};
-
-uart0: serial@2530c00 {
- compatible = "ns16550a";
- clocks = <&k2g_clks 0x2c 0>;
-};
diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
new file mode 100644
index 000000000000..72633651f0c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI-SCI clock controller node bindings
+
+maintainers:
+ - Nishanth Menon <[email protected]>
+
+allOf:
+ - $ref: /schemas/clock/clock.yaml#
+
+description: |
+ Some TI SoCs contain a system controller (like the Power Management Micro
+ Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
+ the state of the various hardware modules present on the SoC. Communication
+ between the host processor running an OS and the system controller happens
+ through a protocol called TI System Control Interface (TI-SCI protocol).
+
+ This clock controller node uses the TI SCI protocol to perform various clock
+ management of various hardware modules (devices) present on the SoC. This
+ node must be a child node of the associated TI-SCI system controller node.
+
+properties:
+ $nodename:
+ pattern: "^clock-controller$"
+
+ compatible:
+ const: ti,k2g-sci-clk
+
+ "#clock-cells":
+ const: 2
+ description:
+ The two cells represent values that the TI-SCI controller defines.
+
+ The first cell should contain the device ID.
+
+ The second cell should contain the clock ID.
+
+ Please see http://processors.wiki.ti.com/index.php/TISCI for
+ protocol documentation for the values to be used for different devices.
+
+additionalProperties: false
+
+examples:
+ - |
+ k3_clks: clock-controller {
+ compatible = "ti,k2g-sci-clk";
+ #clock-cells = <2>;
+ };
--
2.31.0
On 16/04/2021 09:37, Nishanth Menon wrote:
> Hi,
>
> I understand that the following series belong to various maintainers,
> but, it is a bit better reviewed as a single series for
> cohesiveness.
>
> There are also dts fixups that this series exposes, which is good, but
> I chose to hold them back for now pending binding review at least. The
> complete series is available in [1] if folks are curious.
>
> Nishanth Menon (4):
> dt-bindings: reset: Convert ti,sci-reset to json schema
> dt-bindings: clock: Convert ti,sci-clk to json schema
> dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
> dt-bindings: arm: keystone: Convert ti,sci to json schema
For the whole series:
Reviewed-by: Tero Kristo <[email protected]>
>
> .../bindings/arm/keystone/ti,sci.txt | 86 ------------
> .../bindings/arm/keystone/ti,sci.yaml | 129 ++++++++++++++++++
> .../devicetree/bindings/clock/ti,sci-clk.txt | 36 -----
> .../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++++++
> .../bindings/reset/ti,sci-reset.txt | 62 ---------
> .../bindings/reset/ti,sci-reset.yaml | 51 +++++++
> .../bindings/soc/ti/sci-pm-domain.txt | 65 ---------
> .../bindings/soc/ti/sci-pm-domain.yaml | 59 ++++++++
> 8 files changed, 291 insertions(+), 249 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
> delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
>
> [1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci
>
> Regards,
> Nishanth Menon
>
Quoting Nishanth Menon (2021-04-15 23:37:19)
> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> new file mode 100644
> index 000000000000..72633651f0c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI-SCI clock controller node bindings
> +
> +maintainers:
> + - Nishanth Menon <[email protected]>
> +
> +allOf:
> + - $ref: /schemas/clock/clock.yaml#
Is this needed?
> +
> +description: |
> + Some TI SoCs contain a system controller (like the Power Management Micro
> + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> + the state of the various hardware modules present on the SoC. Communication
> + between the host processor running an OS and the system controller happens
> + through a protocol called TI System Control Interface (TI-SCI protocol).
> +
> + This clock controller node uses the TI SCI protocol to perform various clock
> + management of various hardware modules (devices) present on the SoC. This
> + node must be a child node of the associated TI-SCI system controller node.
> +
> +properties:
> + $nodename:
> + pattern: "^clock-controller$"
Is this nodename pattern check required?
> +
> + compatible:
> + const: ti,k2g-sci-clk
I thought most things keyed off the compatible string.
> +
> + "#clock-cells":
> + const: 2
> + description:
> + The two cells represent values that the TI-SCI controller defines.
> +
> + The first cell should contain the device ID.
> +
> + The second cell should contain the clock ID.
> +
> + Please see http://processors.wiki.ti.com/index.php/TISCI for
> + protocol documentation for the values to be used for different devices.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + k3_clks: clock-controller {
> + compatible = "ti,k2g-sci-clk";
> + #clock-cells = <2>;
> + };
On 16:55-20210416, Stephen Boyd wrote:
> Quoting Nishanth Menon (2021-04-15 23:37:19)
> > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > new file mode 100644
> > index 000000000000..72633651f0c7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > @@ -0,0 +1,52 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: TI-SCI clock controller node bindings
> > +
> > +maintainers:
> > + - Nishanth Menon <[email protected]>
> > +
> > +allOf:
> > + - $ref: /schemas/clock/clock.yaml#
>
> Is this needed?
https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
This standardizes provider properties like '#clock-cells' etc, allowing
you to add more stricter checks or controls in the future if necessary.
while:
https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
is more a consumer node description.
Should I have picked a different yaml as base for a standard clock-controller
base?
>
> > +
> > +description: |
> > + Some TI SoCs contain a system controller (like the Power Management Micro
> > + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > + the state of the various hardware modules present on the SoC. Communication
> > + between the host processor running an OS and the system controller happens
> > + through a protocol called TI System Control Interface (TI-SCI protocol).
> > +
> > + This clock controller node uses the TI SCI protocol to perform various clock
> > + management of various hardware modules (devices) present on the SoC. This
> > + node must be a child node of the associated TI-SCI system controller node.
> > +
> > +properties:
> > + $nodename:
> > + pattern: "^clock-controller$"
>
> Is this nodename pattern check required?
I'd like the definition on rails and not subject to interpretation, and
restrict the kind of subnodes under TISCI controller node.
>
> > +
> > + compatible:
> > + const: ti,k2g-sci-clk
>
> I thought most things keyed off the compatible string.
Yes, they are. I am not sure I understand your question here. Did you
mean to indicate that having $nodename and compatible both are
redundant?
Redundancy was'nt the intent of this schema definition, rather, I'd like
to make sure that it is not upto interpretation or debate as to what the
node name should be: I believe clock-controller is the correct nodename
(without @0x... since this does'nt use reg property) instead of using
clocks, tisci-clock as the node names.
Do you suggest something different?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Stephen,
On 07:51-20210417, Nishanth Menon wrote:
> On 16:55-20210416, Stephen Boyd wrote:
> > Quoting Nishanth Menon (2021-04-15 23:37:19)
> > > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > new file mode 100644
> > > index 000000000000..72633651f0c7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > @@ -0,0 +1,52 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: TI-SCI clock controller node bindings
> > > +
> > > +maintainers:
> > > + - Nishanth Menon <[email protected]>
> > > +
> > > +allOf:
> > > + - $ref: /schemas/clock/clock.yaml#
> >
> > Is this needed?
>
> https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
> This standardizes provider properties like '#clock-cells' etc, allowing
> you to add more stricter checks or controls in the future if necessary.
>
> while:
>
> https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
> is more a consumer node description.
>
> Should I have picked a different yaml as base for a standard clock-controller
> base?
>
Thinking again, I think your comment was to drop the clock.yaml
inclusion, and, as a result this schema can become more stringent..
Could you clarify?
> >
> > > +
> > > +description: |
> > > + Some TI SoCs contain a system controller (like the Power Management Micro
> > > + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > > + the state of the various hardware modules present on the SoC. Communication
> > > + between the host processor running an OS and the system controller happens
> > > + through a protocol called TI System Control Interface (TI-SCI protocol).
> > > +
> > > + This clock controller node uses the TI SCI protocol to perform various clock
> > > + management of various hardware modules (devices) present on the SoC. This
> > > + node must be a child node of the associated TI-SCI system controller node.
> > > +
> > > +properties:
> > > + $nodename:
> > > + pattern: "^clock-controller$"
> >
> > Is this nodename pattern check required?
>
> I'd like the definition on rails and not subject to interpretation, and
> restrict the kind of subnodes under TISCI controller node.
>
> >
> > > +
> > > + compatible:
> > > + const: ti,k2g-sci-clk
> >
> > I thought most things keyed off the compatible string.
>
> Yes, they are. I am not sure I understand your question here. Did you
> mean to indicate that having $nodename and compatible both are
> redundant?
>
> Redundancy was'nt the intent of this schema definition, rather, I'd like
> to make sure that it is not upto interpretation or debate as to what the
> node name should be: I believe clock-controller is the correct nodename
> (without @0x... since this does'nt use reg property) instead of using
> clocks, tisci-clock as the node names.
>
>
> Do you suggest something different?
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On Fri, Apr 16, 2021 at 01:37:17AM -0500, Nishanth Menon wrote:
> Hi,
>
> I understand that the following series belong to various maintainers,
> but, it is a bit better reviewed as a single series for
> cohesiveness.
They need to go in together as patch 4 depends on the others.
>
> There are also dts fixups that this series exposes, which is good, but
> I chose to hold them back for now pending binding review at least. The
> complete series is available in [1] if folks are curious.
>
> Nishanth Menon (4):
> dt-bindings: reset: Convert ti,sci-reset to json schema
> dt-bindings: clock: Convert ti,sci-clk to json schema
> dt-bindings: soc: ti: Convert ti,sci-pm-domain to json schema
> dt-bindings: arm: keystone: Convert ti,sci to json schema
>
> .../bindings/arm/keystone/ti,sci.txt | 86 ------------
> .../bindings/arm/keystone/ti,sci.yaml | 129 ++++++++++++++++++
> .../devicetree/bindings/clock/ti,sci-clk.txt | 36 -----
> .../devicetree/bindings/clock/ti,sci-clk.yaml | 52 +++++++
> .../bindings/reset/ti,sci-reset.txt | 62 ---------
> .../bindings/reset/ti,sci-reset.yaml | 51 +++++++
> .../bindings/soc/ti/sci-pm-domain.txt | 65 ---------
> .../bindings/soc/ti/sci-pm-domain.yaml | 59 ++++++++
> 8 files changed, 291 insertions(+), 249 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> create mode 100644 Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> create mode 100644 Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> delete mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.txt
> create mode 100644 Documentation/devicetree/bindings/reset/ti,sci-reset.yaml
> delete mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
>
> [1] https://github.com/nmenon/linux-2.6-playground/commits/yaml/tisci
>
> Regards,
> Nishanth Menon
> --
> 2.31.0
>
On Sat, Apr 17, 2021 at 07:51:27AM -0500, Nishanth Menon wrote:
> On 16:55-20210416, Stephen Boyd wrote:
> > Quoting Nishanth Menon (2021-04-15 23:37:19)
> > > diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > new file mode 100644
> > > index 000000000000..72633651f0c7
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
> > > @@ -0,0 +1,52 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: TI-SCI clock controller node bindings
> > > +
> > > +maintainers:
> > > + - Nishanth Menon <[email protected]>
> > > +
> > > +allOf:
> > > + - $ref: /schemas/clock/clock.yaml#
> >
> > Is this needed?
No. It is already applied to every node.
> https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
> This standardizes provider properties like '#clock-cells' etc, allowing
> you to add more stricter checks or controls in the future if necessary.
>
> while:
>
> https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
> is more a consumer node description.
No, the meta-schema is what checks the schemas just as the schemas check
dts files.
> Should I have picked a different yaml as base for a standard clock-controller
> base?
>
> >
> > > +
> > > +description: |
> > > + Some TI SoCs contain a system controller (like the Power Management Micro
> > > + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > > + the state of the various hardware modules present on the SoC. Communication
> > > + between the host processor running an OS and the system controller happens
> > > + through a protocol called TI System Control Interface (TI-SCI protocol).
> > > +
> > > + This clock controller node uses the TI SCI protocol to perform various clock
> > > + management of various hardware modules (devices) present on the SoC. This
> > > + node must be a child node of the associated TI-SCI system controller node.
> > > +
> > > +properties:
> > > + $nodename:
> > > + pattern: "^clock-controller$"
> >
> > Is this nodename pattern check required?
>
> I'd like the definition on rails and not subject to interpretation, and
> restrict the kind of subnodes under TISCI controller node.
If this schema was standalone and not defined as part of another, then
yes it would be required. In your case, you can enforce the node name
from the parent schema. For consistency though, it would be better to
just always require $nodename.
Actually, this schema will be applied twice. On it's own matching the
compatible string and by the parent schema. You can prevent that with
'select: false'. I don't mind the double validation as if the parent
node had a compatible typo you'd get zero validation.
>
> >
> > > +
> > > + compatible:
> > > + const: ti,k2g-sci-clk
> >
> > I thought most things keyed off the compatible string.
>
> Yes, they are. I am not sure I understand your question here. Did you
> mean to indicate that having $nodename and compatible both are
> redundant?
>
> Redundancy was'nt the intent of this schema definition, rather, I'd like
> to make sure that it is not upto interpretation or debate as to what the
> node name should be: I believe clock-controller is the correct nodename
> (without @0x... since this does'nt use reg property) instead of using
> clocks, tisci-clock as the node names.
>
>
> Do you suggest something different?
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 17:31-20210421, Rob Herring wrote:
[...]
> > > > +allOf:
> > > > + - $ref: /schemas/clock/clock.yaml#
> > >
> > > Is this needed?
>
> No. It is already applied to every node.
>
> > https://github.com/devicetree-org/dt-schema/blob/master/schemas/clock/clock.yaml
> > This standardizes provider properties like '#clock-cells' etc, allowing
> > you to add more stricter checks or controls in the future if necessary.
> >
> > while:
> >
> > https://github.com/devicetree-org/dt-schema/blob/master/meta-schemas/clocks.yaml
> > is more a consumer node description.
>
> No, the meta-schema is what checks the schemas just as the schemas check
> dts files.
I will drop and respin. thanks for explaining.
>
> > Should I have picked a different yaml as base for a standard clock-controller
> > base?
> >
> > >
> > > > +
> > > > +description: |
> > > > + Some TI SoCs contain a system controller (like the Power Management Micro
> > > > + Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
> > > > + the state of the various hardware modules present on the SoC. Communication
> > > > + between the host processor running an OS and the system controller happens
> > > > + through a protocol called TI System Control Interface (TI-SCI protocol).
> > > > +
> > > > + This clock controller node uses the TI SCI protocol to perform various clock
> > > > + management of various hardware modules (devices) present on the SoC. This
> > > > + node must be a child node of the associated TI-SCI system controller node.
> > > > +
> > > > +properties:
> > > > + $nodename:
> > > > + pattern: "^clock-controller$"
> > >
> > > Is this nodename pattern check required?
> >
> > I'd like the definition on rails and not subject to interpretation, and
> > restrict the kind of subnodes under TISCI controller node.
>
> If this schema was standalone and not defined as part of another, then
> yes it would be required. In your case, you can enforce the node name
> from the parent schema. For consistency though, it would be better to
> just always require $nodename.
>
> Actually, this schema will be applied twice. On it's own matching the
> compatible string and by the parent schema. You can prevent that with
> 'select: false'. I don't mind the double validation as if the parent
> node had a compatible typo you'd get zero validation.
Sure. I will keep nodename.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D