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

[Rob Herring]

On Thu, Feb 12, 2026 at 6:03 AM André Draszik <andre.draszik at linaro.org> wrote:
>
> Hi Rob,
>
> On Wed, 2026-02-11 at 15:12 -0600, Rob Herring wrote:
> > On Thu, Feb 05, 2026 at 09:42:32PM +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.
> > >
> > > Tested-by: Marek Szyprowski <m.szyprowski at samsung.com>
> > > Signed-off-by: André Draszik <andre.draszik at 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.
> >
> > > 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/
> > > 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 at 17460000 {
>                 compatible = "google,gs101-pmu";
>                 reg = <0x17460000 0x10000>;
>         };