linux-kernel - Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via power-domain-map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260127151735.GA1699112-robh@kernel.org>
Date: Tue, 27 Jan 2026 09:17:35 -0600
From: Rob Herring <robh@...nel.org>
To: "Kevin Hilman (TI)" <khilman@...libre.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	devicetree@...r.kernel.org, linux-pm@...r.kernel.org,
	arm-scmi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC v5 1/2] pmdomain: core: support domain hierarchy via
 power-domain-map

On Thu, Jan 22, 2026 at 05:14:00PM -0800, Kevin Hilman (TI) wrote:
> Add of_genpd_[add|remove]_subdomain_map() helper functions to support
> hierarchical PM domains defined by using power-domains-map

power-domain-map. No 's'.

> property (c.f. nexus node maps in DT spec, section 2.5.1).
> 
> This enables PM domain providers with #power-domain-cells > 0 to
> establish subdomain relationships via the power-domain-map property,
> which was not previously possible.
> 
> These new helper functions:
> - uses an OF helper to iterate to over entries in power-domain-map
> - For each mapped entry: extracts child specifier, resolves parent phandle,
>   extracts parent specifier args, and establishes subdomain relationship
> - Calls genpd_[add|remove]_subdomain() with proper gpd_list_lock mutex protection
> 
> Example from k3-am62l.dtsi:
> 
>   scmi_pds: protocol@11 {
>       #power-domain-cells = <1>;
>       power-domain-map = <15 &MAIN_PD>,  /* TIMER0 */
>                          <19 &WKUP_PD>;  /* WKUP_TIMER0 */
>   };
> 
>   MAIN_PD: power-controller-main {
>       #power-domain-cells = <0>;
>   };
> 
>   WKUP_PD: power-controller-main {
>       #power-domain-cells = <0>;
>   };
> 
> This allows SCMI power domain 15 to become a subdomain of MAIN_PD, and
> domain 19 to become a subdomain of WKUP_PD.

One concern I have here is generally *-map is transparent meaning when 
you lookup <&scmi_pds 15>, &MAIN_PD is returned as the provider. It's 
also possible to have a map point to another map until you get to the 
final provider. The only way we have to support both behaviors is the 
consumer has to specify (i.e. with of_parse_phandle_with_args_map() vs. 
of_parse_phandle_with_args()), but the consumer shouldn't really know 
this detail.

Maybe a transparent map of power-domains would never make sense. IDK. If 
so, then there's not really any issue since the pmdomain core handles 
everyone the same way.

Rob