From: Conor Dooley <conor.dooley@microchip.com>

There are two syscons on PolarFire SoC that provide various functionality of
use to the OS.

The first of these is the "control-scb" region, that contains the "tvs"
temperature and voltage sensors and the control/status registers for the
system controller's mailbox. The mailbox has a dedicated node, so
there's no need for a child node describing it, looking the syscon up by
compatible is sufficient.

The second, "mss-top-sysreg", contains clocks, pinctrl, resets, and
interrupt controller and more. For this RFC, only the reset controller
child is described as that's all that is described by the existing
bindings. The clock controller already has a dedicated node, and will
retain it as there are other clock regions, so like the mailbox,
a compatible-based lookup of the syscon is sufficient to keep the clock
driver working as before so no child is needed.

Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
(I'll split this in two later, it's just easier when I have the same
questions about both...)

Are these things entitled to have child nodes for the reset and sensor
nodes, or should the properties be in the parent and the OS probe the
drivers for the functions? That's something that, despite supposedly
being a maintainer, I do not understand the rules (of thumb?) for.

Secondly, is it okay to make the "pragmatic" decision to not have a
child clock node and keep routing the clocks via the existing & retained
clock node (and therefore not update the various clocks nodes in the
consumers)? Doing so would require a lot more hocus pocus with the clock
driver than this series does, as the same driver would no longer be
suitable for the before/after bindings.
---
 .../microchip/microchip,mpfs-control-scb.yaml | 54 +++++++++++++++++++
 .../microchip,mpfs-mss-top-sysreg.yaml        | 53 ++++++++++++++++++
 2 files changed, 107 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
 create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml

diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
new file mode 100644
index 000000000000..3673bf139ce8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/microchip/microchip,mpfs-control-scb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC System Controller Bus (SCB) Control Register region
+
+maintainers:
+  - Conor Dooley <conor.dooley@microchip.com>
+
+description:
+  An assortment of system controller related registers, including voltage and
+  temperature sensors and the status/control registers for the system
+  controller's mailbox.
+
+properties:
+  compatible:
+    items:
+      - const: microchip,mpfs-control-scb
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  sensor:
+    type: object
+
+    properties:
+      compatible:
+        const: microchip,mpfs-tvs
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+      syscon@37020000 {
+        compatible = "microchip,mpfs-control-scb", "syscon", "simple-mfd";
+        reg = <0x37020000 0x100>;
+
+        sensor {
+          compatible = "microchip,mpfs-tvs";
+        };
+      };
+    };
+
diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
new file mode 100644
index 000000000000..d70c9c3348ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PolarFire SoC Microprocessor Subsystem (MSS) sysreg Register region
+
+maintainers:
+  - Conor Dooley <conor.dooley@microchip.com>
+
+description:
+  An wide assortment of registers that control elements of the MSS on PolarFire
+  SoC, including pinmuxing, resets and clocks among others.
+
+properties:
+  compatible:
+    items:
+      - const: microchip,mpfs-mss-top-sysreg
+      - const: syscon
+      - const: simple-mfd
+
+  reg:
+    maxItems: 1
+
+  reset-controller:
+    type: object
+
+    properties:
+      compatible:
+        const: microchip,mpfs-reset
+
+      '#reset-cells':
+        description:
+          The AHB/AXI peripherals on the PolarFire SoC have reset support, so
+          from CLK_ENVM to CLK_CFM. The reset consumer should specify the
+          desired peripheral via the clock ID in its "resets" phandle cell.
+          See include/dt-bindings/clock/microchip,mpfs-clock.h for the full list
+          of PolarFire clock/reset IDs.
+        const: 1
+
+    additionalProperties: false
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+    };
+
-- 
2.43.0

On Thu, Aug 15, 2024 at 03:01:09PM +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> There are two syscons on PolarFire SoC that provide various functionality of
> use to the OS.
> 
> The first of these is the "control-scb" region, that contains the "tvs"
> temperature and voltage sensors and the control/status registers for the
> system controller's mailbox. The mailbox has a dedicated node, so
> there's no need for a child node describing it, looking the syscon up by
> compatible is sufficient.
> 
> The second, "mss-top-sysreg", contains clocks, pinctrl, resets, and
> interrupt controller and more. For this RFC, only the reset controller
> child is described as that's all that is described by the existing
> bindings. The clock controller already has a dedicated node, and will
> retain it as there are other clock regions, so like the mailbox,
> a compatible-based lookup of the syscon is sufficient to keep the clock
> driver working as before so no child is needed.

I'm confused. The reset controller is reused from somewhere else? I 
thought you didn't expect any reuse of the IP happening. If a child node 
makes it possible to enable the h/w without any s/w changes, then that 
is a compelling argument for having a child node.

> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> (I'll split this in two later, it's just easier when I have the same
> questions about both...)
> 
> Are these things entitled to have child nodes for the reset and sensor
> nodes, or should the properties be in the parent and the OS probe the
> drivers for the functions? That's something that, despite supposedly
> being a maintainer, I do not understand the rules (of thumb?) for.

Besides the is it an independent, reusable IP block test, my test 
generally is do the child nodes have their own DT resources? Say 
you have phy registers mixed in some syscon and clocks which only go to 
the phy. Then a child node with "clocks" makes sense. If your only 
property is #phy-cells, then a child node doesn't make sense. Of course 
you could reach different conclusions based on the completeness of the 
binding.

> 
> Secondly, is it okay to make the "pragmatic" decision to not have a
> child clock node and keep routing the clocks via the existing & retained
> clock node (and therefore not update the various clocks nodes in the
> consumers)? Doing so would require a lot more hocus pocus with the clock
> driver than this series does, as the same driver would no longer be
> suitable for the before/after bindings.

In the 2 cases here, I don't think you need child nodes. I would expect 
pinctrl to have one though if only as a container for all the pinctrl 
child nodes.

Rob

On Thu, Aug 15, 2024 at 02:00:03PM -0600, Rob Herring wrote:
> On Thu, Aug 15, 2024 at 03:01:09PM +0100, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> > 
> > There are two syscons on PolarFire SoC that provide various functionality of
> > use to the OS.
> > 
> > The first of these is the "control-scb" region, that contains the "tvs"
> > temperature and voltage sensors and the control/status registers for the
> > system controller's mailbox. The mailbox has a dedicated node, so
> > there's no need for a child node describing it, looking the syscon up by
> > compatible is sufficient.
> > 
> > The second, "mss-top-sysreg", contains clocks, pinctrl, resets, and
> > interrupt controller and more. For this RFC, only the reset controller
> > child is described as that's all that is described by the existing
> > bindings. The clock controller already has a dedicated node, and will
> > retain it as there are other clock regions, so like the mailbox,
> > a compatible-based lookup of the syscon is sufficient to keep the clock
> > driver working as before so no child is needed.
> 
> I'm confused. The reset controller is reused from somewhere else?

There's already a driver for it on this device, but probed via the
auxiliary bus, and the #reset-cells property is in the clock controller
node. The only devices that use this driver are the various different
logic element SKUs (which all share a compatible, they're identical as
far as an OS is concerned) and an upcoming SoC that is effectively a
zero logic element SKU.

> I 
> thought you didn't expect any reuse of the IP happening.

> If a child node 
> makes it possible to enable the h/w without any s/w changes, then that 
> is a compelling argument for having a child node.

No, in both cases there'd be software changes - they're just simpler
with a child node.

> 
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> > (I'll split this in two later, it's just easier when I have the same
> > questions about both...)
> > 
> > Are these things entitled to have child nodes for the reset and sensor
> > nodes, or should the properties be in the parent and the OS probe the
> > drivers for the functions? That's something that, despite supposedly
> > being a maintainer, I do not understand the rules (of thumb?) for.
> 
> Besides the is it an independent, reusable IP block test, my test 
> generally is do the child nodes have their own DT resources? Say 
> you have phy registers mixed in some syscon and clocks which only go to 
> the phy. Then a child node with "clocks" makes sense. If your only 
> property is #phy-cells, then a child node doesn't make sense. Of course 
> you could reach different conclusions based on the completeness of the 
> binding.

AFAIK, none of these things are consumers of resources like that, other
than the interrupt controller, which has an interrupts property. I think
that could justify a child node (and I think a dedicated binding,
because it is a confusing irq mux that that kernel doesn't appear to
have anything else similar to).

> > Secondly, is it okay to make the "pragmatic" decision to not have a
> > child clock node and keep routing the clocks via the existing & retained
> > clock node (and therefore not update the various clocks nodes in the
> > consumers)? Doing so would require a lot more hocus pocus with the clock
> > driver than this series does, as the same driver would no longer be
> > suitable for the before/after bindings.
> 
> In the 2 cases here, I don't think you need child nodes. I would expect 
> pinctrl to have one though if only as a container for all the pinctrl 
> child nodes.

Good to know for when that gets written. Hopefully not by me, I have
enough messes to sort out as is!

Cheers,
Conor.

On Thu, Aug 15, 2024 at 03:01:09PM +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> There are two syscons on PolarFire SoC that provide various functionality of
> use to the OS.
> 
> The first of these is the "control-scb" region, that contains the "tvs"
> temperature and voltage sensors and the control/status registers for the
> system controller's mailbox. The mailbox has a dedicated node, so
> there's no need for a child node describing it, looking the syscon up by
> compatible is sufficient.
> 
> The second, "mss-top-sysreg", contains clocks, pinctrl, resets, and
> interrupt controller and more. For this RFC, only the reset controller
> child is described as that's all that is described by the existing
> bindings. The clock controller already has a dedicated node, and will
> retain it as there are other clock regions, so like the mailbox,
> a compatible-based lookup of the syscon is sufficient to keep the clock
> driver working as before so no child is needed.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> (I'll split this in two later, it's just easier when I have the same
> questions about both...)
> 
> Are these things entitled to have child nodes for the reset and sensor
> nodes, or should the properties be in the parent and the OS probe the
> drivers for the functions? That's something that, despite supposedly
> being a maintainer, I do not understand the rules (of thumb?) for.

After posting a link to this on the devicetree irc channel, I had some
discussion with Mark Brown about whether or not the functions described
by the child nodes were ever likely to be independently reused. Given that
they're pretty closely tied to the integration of this particular SoC-FPGA
I think it is unlikely to happen. Reading between the lines, I'm going
to chalk that up as one vote against child nodes being suitable here.

Cheers,
Conor.

> 
> Secondly, is it okay to make the "pragmatic" decision to not have a
> child clock node and keep routing the clocks via the existing & retained
> clock node (and therefore not update the various clocks nodes in the
> consumers)? Doing so would require a lot more hocus pocus with the clock
> driver than this series does, as the same driver would no longer be
> suitable for the before/after bindings.
>
> ---
>  .../microchip/microchip,mpfs-control-scb.yaml | 54 +++++++++++++++++++
>  .../microchip,mpfs-mss-top-sysreg.yaml        | 53 ++++++++++++++++++
>  2 files changed, 107 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
>  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
> 
> diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
> new file mode 100644
> index 000000000000..3673bf139ce8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/microchip/microchip,mpfs-control-scb.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip PolarFire SoC System Controller Bus (SCB) Control Register region
> +
> +maintainers:
> +  - Conor Dooley <conor.dooley@microchip.com>
> +
> +description:
> +  An assortment of system controller related registers, including voltage and
> +  temperature sensors and the status/control registers for the system
> +  controller's mailbox.
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: microchip,mpfs-control-scb
> +      - const: syscon
> +      - const: simple-mfd
> +
> +  reg:
> +    maxItems: 1
> +
> +  sensor:
> +    type: object
> +
> +    properties:
> +      compatible:
> +        const: microchip,mpfs-tvs
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    soc {
> +      syscon@37020000 {
> +        compatible = "microchip,mpfs-control-scb", "syscon", "simple-mfd";
> +        reg = <0x37020000 0x100>;
> +
> +        sensor {
> +          compatible = "microchip,mpfs-tvs";
> +        };
> +      };
> +    };
> +
> diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
> new file mode 100644
> index 000000000000..d70c9c3348ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip PolarFire SoC Microprocessor Subsystem (MSS) sysreg Register region
> +
> +maintainers:
> +  - Conor Dooley <conor.dooley@microchip.com>
> +
> +description:
> +  An wide assortment of registers that control elements of the MSS on PolarFire
> +  SoC, including pinmuxing, resets and clocks among others.
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: microchip,mpfs-mss-top-sysreg
> +      - const: syscon
> +      - const: simple-mfd
> +
> +  reg:
> +    maxItems: 1
> +
> +  reset-controller:
> +    type: object
> +
> +    properties:
> +      compatible:
> +        const: microchip,mpfs-reset
> +
> +      '#reset-cells':
> +        description:
> +          The AHB/AXI peripherals on the PolarFire SoC have reset support, so
> +          from CLK_ENVM to CLK_CFM. The reset consumer should specify the
> +          desired peripheral via the clock ID in its "resets" phandle cell.
> +          See include/dt-bindings/clock/microchip,mpfs-clock.h for the full list
> +          of PolarFire clock/reset IDs.
> +        const: 1
> +
> +    additionalProperties: false
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    soc {
> +    };
> +
> -- 
> 2.43.0
> 

On Thu, 15 Aug 2024 15:01:09 +0100, Conor Dooley wrote:
> From: Conor Dooley <conor.dooley@microchip.com>
> 
> There are two syscons on PolarFire SoC that provide various functionality of
> use to the OS.
> 
> The first of these is the "control-scb" region, that contains the "tvs"
> temperature and voltage sensors and the control/status registers for the
> system controller's mailbox. The mailbox has a dedicated node, so
> there's no need for a child node describing it, looking the syscon up by
> compatible is sufficient.
> 
> The second, "mss-top-sysreg", contains clocks, pinctrl, resets, and
> interrupt controller and more. For this RFC, only the reset controller
> child is described as that's all that is described by the existing
> bindings. The clock controller already has a dedicated node, and will
> retain it as there are other clock regions, so like the mailbox,
> a compatible-based lookup of the syscon is sufficient to keep the clock
> driver working as before so no child is needed.
> 
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> (I'll split this in two later, it's just easier when I have the same
> questions about both...)
> 
> Are these things entitled to have child nodes for the reset and sensor
> nodes, or should the properties be in the parent and the OS probe the
> drivers for the functions? That's something that, despite supposedly
> being a maintainer, I do not understand the rules (of thumb?) for.
> 
> Secondly, is it okay to make the "pragmatic" decision to not have a
> child clock node and keep routing the clocks via the existing & retained
> clock node (and therefore not update the various clocks nodes in the
> consumers)? Doing so would require a lot more hocus pocus with the clock
> driver than this series does, as the same driver would no longer be
> suitable for the before/after bindings.
> ---
>  .../microchip/microchip,mpfs-control-scb.yaml | 54 +++++++++++++++++++
>  .../microchip,mpfs-mss-top-sysreg.yaml        | 53 ++++++++++++++++++
>  2 files changed, 107 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
>  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:21.13-38: Warning (reg_format): /example-0/soc/syscon@37020000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:19.27-26.13: Warning (avoid_default_addr_size): /example-0/soc/syscon@37020000: Relying on default #address-cells value
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:19.27-26.13: Warning (avoid_default_addr_size): /example-0/soc/syscon@37020000: Relying on default #size-cells value
Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size'

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240815-pending-sacrifice-f2569ed756fe@spud

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

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 after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

On Thu, Aug 15, 2024 at 09:34:11AM -0600, Rob Herring (Arm) wrote:
> 
> On Thu, 15 Aug 2024 15:01:09 +0100, Conor Dooley wrote:
> > From: Conor Dooley <conor.dooley@microchip.com>
> > 
> > There are two syscons on PolarFire SoC that provide various functionality of
> > use to the OS.
> > 
> > The first of these is the "control-scb" region, that contains the "tvs"
> > temperature and voltage sensors and the control/status registers for the
> > system controller's mailbox. The mailbox has a dedicated node, so
> > there's no need for a child node describing it, looking the syscon up by
> > compatible is sufficient.
> > 
> > The second, "mss-top-sysreg", contains clocks, pinctrl, resets, and
> > interrupt controller and more. For this RFC, only the reset controller
> > child is described as that's all that is described by the existing
> > bindings. The clock controller already has a dedicated node, and will
> > retain it as there are other clock regions, so like the mailbox,
> > a compatible-based lookup of the syscon is sufficient to keep the clock
> > driver working as before so no child is needed.
> > 
> > Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> > ---
> > (I'll split this in two later, it's just easier when I have the same
> > questions about both...)
> > 
> > Are these things entitled to have child nodes for the reset and sensor
> > nodes, or should the properties be in the parent and the OS probe the
> > drivers for the functions? That's something that, despite supposedly
> > being a maintainer, I do not understand the rules (of thumb?) for.
> > 
> > Secondly, is it okay to make the "pragmatic" decision to not have a
> > child clock node and keep routing the clocks via the existing & retained
> > clock node (and therefore not update the various clocks nodes in the
> > consumers)? Doing so would require a lot more hocus pocus with the clock
> > driver than this series does, as the same driver would no longer be
> > suitable for the before/after bindings.
> > ---
> >  .../microchip/microchip,mpfs-control-scb.yaml | 54 +++++++++++++++++++
> >  .../microchip,mpfs-mss-top-sysreg.yaml        | 53 ++++++++++++++++++
> >  2 files changed, 107 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.yaml
> >  create mode 100644 Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-mss-top-sysreg.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:21.13-38: Warning (reg_format): /example-0/soc/syscon@37020000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (pci_device_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:19.27-26.13: Warning (avoid_default_addr_size): /example-0/soc/syscon@37020000: Relying on default #address-cells value
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dts:19.27-26.13: Warning (avoid_default_addr_size): /example-0/soc/syscon@37020000: Relying on default #size-cells value
> Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-control-scb.example.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size'

Yeah, these are all known. One of the bindings doesn't even have an
example. I know this is automated, but just to point out that my only
objective here is figuring out whether or not child nodes are okay here.