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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJZ5v0jeMqmeZiVQ_EbZrR0XTMfHwg4fEdVmz1p9S-R-VOCVZw@mail.gmail.com>
Date: Thu, 10 Apr 2025 11:55:29 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Miquel Raynal <miquel.raynal@...tlin.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, 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,

On Thu, Apr 10, 2025 at 9:54 AM Miquel Raynal <miquel.raynal@...tlin.com> wrote:
>
> 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.

Which means DT because fw_devlink=rpm is DT-specific.  At least it is
not used on systems where ACPI is the firmware interface.

> > 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?

Well, see above.

> 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.

So you know which devices are parents and children without fw_devlink
and this information can be used readily on all systems AFAICS.

IIUC, the overall approach is to resume the entire hierarchy before
making changes that may deadlock and I think that this is a good idea
in general.

However, you need to do it in a way that's usable on all systems and
when you walk the hierarchy from top to bottom, you need to do it
recursively I think because resuming a device doesn't cause its
children or consumers to resume.