linux-kernel - Re: [PATCH RFC 01/10] PM: runtime: Add helpers to resume consumers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <875xjccuyx.fsf@bootlin.com>
Date: Thu, 10 Apr 2025 09:54:30 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Pavel Machek <pavel@....cz>,  Len Brown <len.brown@...el.com>,  Greg
 Kroah-Hartman <gregkh@...uxfoundation.org>,  Danilo Krummrich
 <dakr@...nel.org>,  Michael Turquette <mturquette@...libre.com>,  Stephen
 Boyd <sboyd@...nel.org>,  Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
  linux-pm@...r.kernel.org,  linux-kernel@...r.kernel.org,
  linux-clk@...r.kernel.org,  Chen-Yu Tsai <wenst@...omium.org>,  Lucas
 Stach <l.stach@...gutronix.de>,  Laurent Pinchart
 <laurent.pinchart@...asonboard.com>,  Marek Vasut <marex@...x.de>,  Ulf
 Hansson <ulf.hansson@...aro.org>,  Kevin Hilman <khilman@...nel.org>,
  Fabio Estevam <festevam@...x.de>,  Jacky Bai <ping.bai@....com>,  Peng
 Fan <peng.fan@....com>,  Shawn Guo <shawnguo@...nel.org>,  Shengjiu Wang
 <shengjiu.wang@....com>,  linux-imx@....com,  Ian Ray
 <ian.ray@...ealthcare.com>,  Hervé Codina
 <herve.codina@...tlin.com>,
  Luca Ceresoli <luca.ceresoli@...tlin.com>,  Saravana Kannan
 <saravanak@...gle.com>
Subject: Re: [PATCH RFC 01/10] PM: runtime: Add helpers to resume consumers

Hi Rafael,

Thanks for taking the time to read all that.

>> After the LPC discussion with Steven, I also discussed with Saravana
>> about this and he pointed that since we were using fw_devlink=rpm by
>> default now, all providers -including clock controllers of course- would
>> already be runtime resumed the first time we would make a
>> runtime_resume(clk), and thus all the nested calls were no longer
>> needed. This native solution was already addressing point #1 above (and
>> partially point #3) and all I had to do was to make a similar function
>> for point #2.
>
> So this depends on DT being used and fw_devlink=rpm being used,
> doesn't it?

DT, not really. fw_devlink=rpm however, yes.

> You cannot really assume in general that there will be device links
> between parents and children.

But if runtime PM already mandates fw_devlink to be the information
source (which, IIRC is the case since fw_devlink=rpm), then why wouldn't
this approach work? For sure there may be holes in fw_devlink, but
what is the reason for it if we cannot use it?

In other words, are you suggesting that this approach is invalid? If yes
could you elaborate a bit? For this approach to work we do not need all
the parenting to be perfectly described, just relationships between
clock consumers and providers, which are in general rather basic.

Thanks,
Miquèl