linux-kernel - Re: [PATCH v1 00/10] PM: Make the core and pm_runtime_force

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: <CAPDyKFroyU3YDSfw_Y6k3giVfajg3NQGwNWeteJWqpW29BojhQ@mail.gmail.com>
Date: Wed, 12 Feb 2025 10:12:16 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Alan Stern <stern@...land.harvard.edu>, Johan Hovold <johan@...nel.org>, 
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>, Jon Hunter <jonathanh@...dia.com>
Subject: Re: [PATCH v1 00/10] PM: Make the core and pm_runtime_force_suspend/resume()
 agree more

On Tue, 11 Feb 2025 at 22:25, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>
> Hi Everyone,
>
> This series is a result of the discussion on a recently reported issue
> with device runtime PM status propagation during system resume and
> the resulting patches:
>
> https://lore.kernel.org/linux-pm/12619233.O9o76ZdvQC@rjwysocki.net/
> https://lore.kernel.org/linux-pm/6137505.lOV4Wx5bFT@rjwysocki.net/
>
> Overall, due to restrictions related to pm_runtime_force_suspend() and
> pm_runtime_force_resume(), it was necessary to limit the RPM_ACTIVE
> setting propagation to the parent of the first device in a dependency
> chain that turned out to have to be resumed during system resume even
> though it was runtime-suspended before system suspend.
>
> Those restrictions are that (1) pm_runtime_force_suspend() attempts to
> suspend devices that have never had runtime PM enabled if their runtime
> PM status is currently RPM_ACTIVE and (2) pm_runtime_force_resume()
> will skip device whose runtime PM status is currently RPM_ACTIVE.
>
> The purpose of this series is to eliminate the above restrictions and
> get pm_runtime_force_suspend() and pm_runtime_force_resume() to agree
> more with what the core does.

For my understanding, would you mind elaborating a bit more around the
end-goal with this?

Are you trying to make adaptations for
pm_runtime_force_suspend|resume() and the PM core, such that drivers
that uses pm_runtime_force_suspend|resume() should be able to cope
with other drivers for child-devices that make use of
DPM_FLAG_SMART_SUSPEND?

If we can make this work, it would enable the propagation of
RPM_ACTIVE in the PM core for more devices, but still not for all,
right?

The point is, the other bigger issue that I pointed out in our earlier
discussions; all those devices where their drivers/buses don't cope
with the behaviour of the DPM_FLAG_SMART_SUSPEND flag, will prevent
the PM core from *unconditionally* propagating the RPM_ACTIVE to
parents. I guess this is the best we can do then?

>
> First off, it turns out that detecting devices that have never had
> runtime PM enabled is not really hard - it is sufficient to check
> their power.last_status data when runtime PM is disabled.  If
> power.last_status is RPM_INVALID at that point, runtime PM has never
> been enabled for the given device, so patch [01/10] adds a helper
> function for checking that.
>
> Patch [02/10] makes the PM core use the new function to avoid setting
> power.set_active for devices with no runtime PM support which really
> is a fixup on top of
>
> https://lore.kernel.org/linux-pm/6137505.lOV4Wx5bFT@rjwysocki.net/
>
> Patch [03/10] modifies pm_runtime_force_suspend() to skip devices
> with no runtime PM support with the help of the new function.
>
> Next, patch [04/10] uses the observation that the runtime PM status
> check in pm_runtime_force_resume() is redundant and drops that check.
>
> Patch [05/10] removes the wakeirq enabling from the pm_runtime_force_resume()
> error path because it is not really a good idea to enable wakeirqs during
> system resume.
>
> Patch [06/10] makes the PM core somewhat more consistent with
> pm_runtime_force_suspend() and patch [07/10] prepares it for the subsequent
> changes.
>
> Patch [08/10] changes pm_runtime_force_resume() to handle the case in
> which the runtime PM status of the device has been updated by the core to
> RPM_ACTIVE after pm_runtime_force_suspend() left it in RPM_SUSPENDED.
>
> Patch [09/10] restores the RPM_ACTIVE setting propagation to parents
> and suppliers, but it takes exceptions into account (for example, devices
> with no runtime PM support).
>
> Finally, patch [10/10] adds a mechanism to discover cases in which runtime PM
> is disabled for a device permanently even though it has been enabled for that
> device at one point.
>
> Please have a look and let me know if you see any problems.
>
> Thanks!

Kind regards
Uffe