The power domains are a property of / implemented in the PMU. As such,
they should be modelled as child nodes of the PMU.

Note:
Because the properties added are 'required', this commit breaks DT
validation of the existing DT for Pixel 6, but a) that's simply because
the DT is incomplete and b) a DT update will be posted once the binding
is accepted.
It is not possible to write the binding such that it supports old
(incomplete) DTs in addition to the full version, but as per above
it's not required to keep supporting old DTs.

Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
v8:
- move comment from commit message footer into body (Rob)
- fix incorrect use of ranges in example (Rob)

v7:
- really be consistent with quoting (Krzysztof)
- drop invalid tested-by tag (Krzysztof)

v4:
- consistent quoting using " (Krzysztof)
- add samsung,dtzpc to example
---
 .../bindings/soc/google/google,gs101-pmu.yaml      | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
index a06bd8ec3c20..52c47252b801 100644
--- a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
@@ -16,6 +16,14 @@ properties:
   reg:
     maxItems: 1
 
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 1
+
+  ranges: true
+
   reboot-mode:
     $ref: /schemas/power/reset/syscon-reboot-mode.yaml
     type: object
@@ -39,9 +47,23 @@ properties:
     description:
       Phandle to PMU interrupt generation interface.
 
+patternProperties:
+  "^power-domain@[0-9a-f]+$":
+    type: object
+    description: Child node describing one power domain within the PMU
+
+    additionalProperties: true
+
+    properties:
+      compatible:
+        const: google,gs101-pd
+
 required:
   - compatible
   - reg
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
   - google,pmu-intr-gen-syscon
 
 additionalProperties: false
@@ -51,6 +73,25 @@ examples:
     system-controller@17460000 {
         compatible = "google,gs101-pmu";
         reg = <0x17460000 0x10000>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges = <0x0 0x17460000 0x10000>;
 
         google,pmu-intr-gen-syscon = <&pmu_intr_gen>;
+
+        pd_g3d: power-domain@1e00 {
+            compatible = "google,gs101-pd";
+            reg = <0x1e00 0x80>;
+            #power-domain-cells = <0>;
+            label = "g3d";
+            samsung,dtzpc = <&pd_g3d>;
+        };
+
+        power-domain@2000 {
+            compatible = "google,gs101-pd";
+            reg = <0x2000 0x80>;
+            #power-domain-cells = <0>;
+            power-domains = <&pd_g3d>;
+            label = "embedded_g3d";
+        };
     };

-- 
2.53.0.851.ga537e3e6e9-goog

On Wed, 18 Mar 2026 15:27:49 +0000, André Draszik wrote:
> The power domains are a property of / implemented in the PMU. As such,
> they should be modelled as child nodes of the PMU.
> 
> Note:
> Because the properties added are 'required', this commit breaks DT
> validation of the existing DT for Pixel 6, but a) that's simply because
> the DT is incomplete and b) a DT update will be posted once the binding
> is accepted.
> It is not possible to write the binding such that it supports old
> (incomplete) DTs in addition to the full version, but as per above
> it's not required to keep supporting old DTs.
> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
> v8:
> - move comment from commit message footer into body (Rob)
> - fix incorrect use of ranges in example (Rob)
> 
> v7:
> - really be consistent with quoting (Krzysztof)
> - drop invalid tested-by tag (Krzysztof)
> 
> v4:
> - consistent quoting using " (Krzysztof)
> - add samsung,dtzpc to example
> ---
>  .../bindings/soc/google/google,gs101-pmu.yaml      | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

On 18/03/2026 16:27, André Draszik wrote:
> The power domains are a property of / implemented in the PMU. As such,
> they should be modelled as child nodes of the PMU.
> 
> Note:
> Because the properties added are 'required', this commit breaks DT
> validation of the existing DT for Pixel 6, but a) that's simply because
> the DT is incomplete and b) a DT update will be posted once the binding
> is accepted.
> It is not possible to write the binding such that it supports old
> (incomplete) DTs in addition to the full version, but as per above
> it's not required to keep supporting old DTs.
> 
> Signed-off-by: André Draszik <andre.draszik@linaro.org>
> ---
> v8:
> - move comment from commit message footer into body (Rob)
> - fix incorrect use of ranges in example (Rob)
> 
> v7:
> - really be consistent with quoting (Krzysztof)
> - drop invalid tested-by tag (Krzysztof)
> 
> v4:
> - consistent quoting using " (Krzysztof)
> - add samsung,dtzpc to example
> ---
>  .../bindings/soc/google/google,gs101-pmu.yaml      | 41 ++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
> index a06bd8ec3c20..52c47252b801 100644
> --- a/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/google/google,gs101-pmu.yaml
> @@ -16,6 +16,14 @@ properties:
>    reg:
>      maxItems: 1
>  
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 1
> +
> +  ranges: true
> +
>    reboot-mode:
>      $ref: /schemas/power/reset/syscon-reboot-mode.yaml
>      type: object
> @@ -39,9 +47,23 @@ properties:
>      description:
>        Phandle to PMU interrupt generation interface.
>  
> +patternProperties:
> +  "^power-domain@[0-9a-f]+$":
> +    type: object
> +    description: Child node describing one power domain within the PMU
> +
> +    additionalProperties: true
> +
> +    properties:
> +      compatible:
> +        const: google,gs101-pd
> +
>  required:
>    - compatible
>    - reg
> +  - "#address-cells"
> +  - "#size-cells"
> +  - ranges

This causes warnings, so I dropped the patches. I really do not
understand how this is organized. This is not a dependency for pm
domains driver but it is included here. It is a soft dependency for DTS,
but that is nowhere to be found.

Best regards,
Krzysztof

On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
> 
> This causes warnings, so I dropped the patches.

I assume warnings are because I didn't make it clear enough that patch
2 is actually required?

> I really do not
> understand how this is organized. This is not a dependency for pm
> domains driver but it is included here.

The binding is being updated, and the driver follows suit. 
I particular, the driver needs to be aware that pd is (can be) a child
of pmu.

Yes, the driver does not depend on this binding update, but it shows what
the driver must support. I believe this is what we have done in the past:
binding and driver updates in same series.

I could move patches 3 and 4 from this series together with a DTS
update patch into a separate series, if that would be deemed a better
approach?

> It is a soft dependency for DTS,
> but that is nowhere to be found.

I was waiting for review of all binding changes before posting DTS.

Cheers,
Andre'

On 30/03/2026 14:00, André Draszik wrote:
> On Sat, 2026-03-21 at 20:14 +0100, Krzysztof Kozlowski wrote:
>>
>> This causes warnings, so I dropped the patches.
> 
> I assume warnings are because I didn't make it clear enough that patch
> 2 is actually required?

No, these are obvious errors coming from bindings. You can try yourself
instead of asking maintainer to run the commands for you...

> 
>> I really do not
>> understand how this is organized. This is not a dependency for pm
>> domains driver but it is included here.
> 
> The binding is being updated, and the driver follows suit. 
> I particular, the driver needs to be aware that pd is (can be) a child
> of pmu.
> 
> Yes, the driver does not depend on this binding update, but it shows what
> the driver must support. I believe this is what we have done in the past:
> binding and driver updates in same series.

Yes, foo-binding goes with foo-driver to foo-subsystem. It does not mean
you put here completely different bindings. Why? Because just like foo
goes to foo-subsystem, then bar-binding goes with bar-driver to
bar-subsystem.

> 
> I could move patches 3 and 4 from this series together with a DTS
> update patch into a separate series, if that would be deemed a better
> approach?

I asked you what are the dependencies and you answer there are some but
you can move it outside of patchset. So are there or are there not
dependencies? If there are, then you cannot move out. But then I ask
what are the dependencies.

It feels like question to trick the maintainer. Maintainer complained,
so you propose whatever he objected to without understanding whether
this is correct or not correct approach.

> 
>> It is a soft dependency for DTS,
>> but that is nowhere to be found.
> 
> I was waiting for review of all binding changes before posting DTS.

That would be fine explanation, if you also read maintainer soc profile
for Samsung and try what is written there. You would see that you
introduced new warnings without any fix possible as far as next is
concerned.

Best regards,
Krzysztof