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

["André Draszik" <andre.draszik@linaro.org>]

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@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.
> 
> > 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.

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:

	pmu_system_controller: system-controller@17460000 {
		compatible = "google,gs101-pmu";
		reg = <0x17460000 0x10000>;
	};

or the new one:

	pmu_system_controller: system-controller@17460000 {
		compatible = "google,gs101-pmu";
		reg = <0x17460000 0x10000>;
		ranges;
		#address-cells = <1>;
		#size-cells = <1>;

		power-domain@1c00 {
			compatible = "google,gs101-pd";
			reg = <0x1c00 0x80>;
			#power-domain-cells = <0>;
			label = "eh";
			samsung,dtzpc = <&dtzpc_eh>;
		};
	};

I.e. in the old case (when binding + DT were incomplete) ranges etc. are
not 'required' (and shouldn't be), while with the power-domain@[0-9a-f]+
child node(s) added, ranges etc must be specified. 

If power-domain@[0-9a-f]+ wasn't a pattern, it'd be easy, but I really want
it to be a pattern, not least because there are so many instances.

What works (at the top level) is:

    dependentRequired:
      power-domain@1e00: [ranges]

but it would require spelling out all the instances instead of a pattern. The
following (or various variations I've tried) doesn't:

    dependentRequired:
      power-domain@.*: [ranges]

I've also tried to come up with something involving dependentSchemas:, but to no
avail.

Similarly,

    allOf:
      - if:
          anyOf:
            - required: [power-domain@1e00]
            - required: [power-domain@2000]
        then:
          required:
            - ranges

works, but when using a regex, it doesn't:

    allOf:
      - if:
          anyOf:
            - required: [power-domain@.*]
        then:
          required:
            - ranges

I've also tried:

    allOf:
      - if:
          required:
            - "^power-domain@[0-9a-f]+$"
        then:
          required:
            - ranges

and

    anyOf:
      - required:
          - power-domain@1e00
          - ranges
          - reg
      - required:
          - reg

and

    anyOf:
      - required:
          - "^power-domain@[0-9a-f]+$"
          - ranges
          - reg
      - required:
          - reg

None of these seem to do what I would like (even the non-regex one).


Cheers,
Andre'