Thread (19 messages) 19 messages, 3 authors, 2026-03-03

Re: [PATCH v5 04/10] dt-bindings: soc: google: gs101-pmu: allow power domains as children

From: Rob Herring <robh@kernel.org>
Date: 2026-02-12 20:06:17
Also in: linux-devicetree, linux-pm, linux-samsung-soc, lkml

On Thu, Feb 12, 2026 at 6:03 AM André Draszik [off-list ref] wrote:
Hi Rob,

On Wed, 2026-02-11 at 15:12 -0600, Rob Herring wrote:
quoted
On Thu, Feb 05, 2026 at 09:42:32PM +0000, André Draszik wrote:
quoted
The power domains are a property of / implemented in the PMU. As such,
they should be modelled as child nodes of the PMU.

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
v4:
- consistent quoting using " (Krzysztof)
- add samsung,dtzpc to example

Note: Ideally, the newly added properties (ranges, etc.) should only be
'required' if "^power-domain@[0-9a-f]+$" exists as a patternProperty,
as they're needed only in that case. As-is, this patch now causes
warnings for existing DTs as they don't specify the new properties (and
they shouldn't need to).
We can't have warnings added if they aren't valid.
quoted
Only if DTs are updated to include
power-domains, such an update should also add the new properties.

I've not been able to come up with the correct schema syntax to achieve
that. dependencies, dependentRequired, and dependentSchemas don't seem
to support patterns. Similarly,
  - if:
      required:
        - ...
    then:
      required:
        - ...

doesn't allow patterns in the 'if' block (or I didn't get the syntax
right).

Rob said in
https://lore.kernel.org/all/20251010141357.GA219719-robh@kernel.org/ (local)
that this is a known limitation in json-schema.
For a given compatible, you should either have child nodes or you don't.
The h/w is not variable. So something like this should work:

if:
  properties:
    compatible:
      contains:
        const: foo,bar

then:
  required:
    - ranges
    - '#address-cells'
    - '#size-cells'
Thanks Rob, yes, that works in general, but unfortunately in this case existing
DTs don't specify ranges etc for the google,gs101-pmu compatible. (This binding
is specifically for google,gs101-pmu only anyway).

The above suggestion will cause the same validation warnings for existing DTs
which is no different to just adding those properties to the top-level required:
as my patch is doing. Unless I misunderstood your suggestion.
"google,gs101-pmu" represents some specific h/w. That h/w either has
power domains or it doesn't. So which is it?

The compatible doesn't change with these patches. So I'm not sure how to make
your suggestion work without causing warnings for existing DTs. We can either
have an old incomplete DT+binding:
If this is considered incomplete, then you are going to complete it
and add the child nodes? If so, then the warnings are appropriate.

If you were going to maintain both bindings forever, then you would
probably want a new compatible. Or just drop the properties from
required. Note that if you have child nodes with 'reg' and parent
missing #address-cells or #size-cells, then dtc will warn about that.
So it's not too important if the schema doesn't.
        pmu_system_controller: system-controller@17460000 {
                compatible = "google,gs101-pmu";
                reg = <0x17460000 0x10000>;
        };
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help