[Discussion] Design intent behind the parent-child topology in power domain

[lifegameronmyway]

RT-Thread Version

5.2.2

Hardware Type/Architectures

power-management

Develop Toolchain

Other

Describe the bug

@GuEe-GUI
Hi GuEe,
While diving into the rt_dm_power_domain framework, I noticed an interesting behavior regarding the hierarchical topology, and I'd like to understand the original design intent from the authors.
Currently, rt_dm_power_domain_register_child() sets child->parent_domain = parent, but it never links the child to the parent's child_nodes list. As a result, the top-down recursive power_on/off logic for child nodes is effectively bypassed.
Additionally, there is no bottom-up dependency guarantee (e.g., ref-counting to ensure a parent is automatically pulled up before a child). Right now, provider drivers seem to be handling these dependencies manually.
Before suggesting any architectural changes, I'd love to hear from the original authors or maintainers: Was this specific behavior intentional?
For instance:
Is this designed for specific SoCs where the hardware itself handles hierarchical power dependencies, rendering software-side list traversal and ref-counting unnecessary?
Was it a deliberate lightweight choice to keep the framework simple and avoid the overhead of a full GenPD-like tree topology?
Or is it simply an early placeholder structure where the topology logic just hasn't been fully closed yet?
Understanding the background and hardware considerations behind this design will really help clarify how we should use and evolve this API. Looking forward to your insights!

Other additional context

No response

[GuEe-GUI]

Yes, It's a bug, the child->list will remove in rt_dm_power_domain_unregister_child, so the child->list should insert to the parent.

[lifegameronmyway]

Thanks for the quick reply and confirmation! That clears things up perfectly. Looking forward to the fix in the upcoming commits~

[lifegameronmyway]

@GuEe-GUI
By the way, regarding the second point I mentioned earlier, I want to clarify the bottom-up dependency logic. Specifically, I mean the mechanism where powering on a child domain should automatically trigger the power-on of its parent domain first. Furthermore, the framework should ideally use ref-counting to ensure the parent stays powered on as long as any of its child domains are active.
Currently, this "turn on child -> auto turn on parent" logic is missing, and we have to rely on provider drivers to handle it manually. Is this automatic pull-up mechanism something we plan to add to the framework in the future, or is it intentionally left to the drivers?

And a small discussion:
In the hardware power tree, the "power off" sequence is usually the exact inverse of the "power on" sequence.
power_on correctly goes Parent -> Child.
However, power_off currently also goes Parent -> Child (it executes domain->power_off(domain) before traversing the child_nodes).
Cutting the parent's power before the children are properly shut down can lead to hardware crashes or bus hangs. Should we reverse the order in rt_dm_power_domain_power_off so it shuts down children first, and then the parent?

[GuEe-GUI]

I think the child should poweroff force if the top device will poweroff, the top device don't care the child.
The behavior is similar to the machine poweroff.

Well, if you have a better example, you can talk to me.

[lifegameronmyway]

Well, the reason I brought this up was mostly gut-level: power_off ought to feel like the inverse of power_on. Thinking it through, though, it gets messier when domains are nested: a parent shutting down can cascade into children, so a child’s power_off may run in a context the child driver did not initiate, and after the parent (or the rail/bus) is already in a state where MMIO or clocks access may no longer behave the same as on a “normal” teardown path. So child power_off ops probably need to be order-tolerant and idempotent (safeguards included), rather than assuming they only run as the symmetric tail of their own power_on.