On Fri, 2026-03-13 at 10:48 +0000, André Draszik wrote:

On Thu, 2026-03-12 at 10:12 -0500, Rob Herring wrote:

quoted

On Fri, Mar 06, 2026 at 10:29:55AM +0000, André Draszik wrote:

quoted

     system-controller@17460000 {
         compatible = "google,gs101-pmu";
         reg = <0x17460000 0x10000>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
 
         google,pmu-intr-gen-syscon = <&pmu_intr_gen>;
+
+        pd_g3d: power-domain@1e00 {
+            compatible = "google,gs101-pd";
+            reg = <0x1e00 0x80>;

I'm assuming 0x1e00 is an offset from 0x17460000. That's not what ranges 
says though. It says both addresses are in the same address space 
(system-controller@17460000 parent's address space). You need:

ranges = <0x0 0x17460000 0x10000>;

Thanks Rob! On gs101, the PD driver can not do direct mmio. Instead it
needs to use the regmap that the parent has created and apply the
offset from the PD's reg property (using struct resource::start)
(patch 7).

When using ranges as per your suggestion that doesn't work anymore,
as resource->start isn't the offset anymore but the final physical
address, and using that in combination with the parent's regmap
doesn't give us the right address anymore.

Is there an alternative other than using completely arbitrary indices
like e.g. rockchip is doing?

My driver could of course peek into the parent and get the parent's
IORESOURCE_MEM and subtract that start address to get the offset
back.

Is that considered clean (enough)?

	ppdev = to_platform_device(dev->parent);
	pres = platform_get_resource(ppdev, IORESOURCE_MEM, 0);

	pd->regmap = syscon_node_to_regmap(dev->parent->of_node);

	pd->configuration_reg = res->start - pres->start;
	pd->status_reg = res->start - pres->start;


Cheers,
Andre'