linux-kernel - Re: [RFC PATCH] pmdomain: arm: scmi_pm_domain: Do lazy init as part of probe

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250610114314.dpfedrbok2pmfgxu@lcpd911>
Date: Tue, 10 Jun 2025 17:13:14 +0530
From: Dhruva Gole <d-gole@...com>
To: Sudeep Holla <sudeep.holla@....com>
CC: Cristian Marussi <cristian.marussi@....com>,
        Ulf Hansson
	<ulf.hansson@...aro.org>, <arm-scmi@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-pm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <vigneshr@...com>,
        <khilman@...libre.com>
Subject: Re: [RFC PATCH] pmdomain: arm: scmi_pm_domain: Do lazy init as part
 of probe

Hi,

On May 30, 2025 at 17:31:08 +0100, Sudeep Holla wrote:
> On Fri, May 30, 2025 at 04:05:27PM +0530, Dhruva Gole wrote:
> > Optimize the SCMI power domain driver to only initialize domains that are
> > actually referenced in the device tree. Previously, the driver would
> > initialize all possible domains up to the maximum ID, which could lead to
> > unnecessary firmware calls and longer probe times.
> > 
> > Key changes:
> > - Scan device tree to identify which power domains are actually referenced
> 
> How do this work with runtime DT overlays ?

Thanks for bringing this up, I hadn't considered runtime DT overlays for
this particular patch.
Off the top of my mind, we can initialize all at probe, but only query state
for referenced ones.

> 
> > - Use bitmap to track needed domains instead of initializing all
> > - Only perform state queries and initialization for referenced domains
> > - Maintain proper array sizing for power domain framework compatibility
> > - Keep full provider structure to support late binding
> > 
> > This optimization reduces probe time and unnecessary firmware interactions
> > by only initializing power domains that are actually used in the system.
> 
> Why is this very specific to power domains only ? This must apply for other
> domains like perf or clock or reset ?

Yes, it should. Starting out with just power domains for now though. I
haven't looked at other places like perf and clock yet.

> 
> > For example, in a system with 100 possible domains but only 3 referenced
> > in the device tree, we now only initialize those 3 domains instead of
> > all 100.
> > 
> 
> Well, how much of these PD will get used in the final products ? I can
> understand the need to use just 3 in devel platforms. Just trying to see
> how realistic is the scenario ? Is there any other optimisation possible
> from the firmware ? Does getting the state of a PD takes so much time
> on the platform in question ?

Well, it's not only about how much time it takes on any particular platform
to query the state of a PD. Even if say it takes 10us to query it, it will
add a whole 1ms to the probe time. This mean 1ms more of boot time, and
perhaps boot time experts can chime in here but every optimisation
possible matters!
ARM systems are usually very strict on boot time requirements.

Even if we somehow optimise the firmware, to me it seems like kernel is
wasting time querrying for something that it doesn't need at that moment.

Just replying here to your next reply on the thread:
> And I missed another point. Someone will soon complain Linux no longer
> turns off unused power domains. So I am inclined against this optimisation.
> We need to consider all the above point before .

I agree on some points like the runtime overlay. However I am not sure
why Linux should be the one to turn OFF power domains that it's
_unaware_ of. "unused" would probably be a wrong assumption to make.
There maybe other entities that would be using power domains that
are not in the device tree. (For eg. an RTOS running on the same system
accessing a PD that is controlled by the SCP firmware but not mentioned in the
device tree.)

While one may argue that's why firmware should be the one to keep ref
counts to avoid resource conflicts, one could also argue that firmwares
could be the one to turn off unused power domains.

Why should the kernel touch something that it hasn't been told about
explicitly in the DT? Isn't the whole point of DT to be the literal
hardware descriptor for the kernel? So if something doesn't exist in the
DT, kernel shouldn't have other places telling it does - in this context
power domains.

-- 
Best regards,
Dhruva Gole
Texas Instruments Incorporated