On Fri, 27 Jun 2025 at 21:29, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > > Hi Everyone, > > This is an update of the series the v2 of which was posted yesterday: > > https://lore.kernel.org/linux-pm/5015172.GXAFRqVoOG@xxxxxxxxxxxxx/ > > and the v1 is here: > > https://lore.kernel.org/linux-pm/22759968.EfDdHjke4D@xxxxxxxxxxxxx/ > > This update reorders the patches (again), updates the changelogs of some of > them and changes the subject of one patch slightly. It also adds a kerneldoc > comment to a new function in patch [5/9]. > > This part of the cover letter still applies: > > "This series addresses a couple of issues related to the integration of runtime > PM with system sleep I was talking about at the OSMP-summit 2025: > > https://lwn.net/Articles/1021332/ > > Most importantly, DPM_FLAG_SMART_SUSPEND cannot be used along with > pm_runtime_force_suspend/resume() due to some conflicting expectations > about the handling of device runtime PM status between these functions > and the PM core. > > Also pm_runtime_force_suspend/resume() currently cannot be used in PCI > drivers and in drivers that collaborate with the general ACPI PM domain > because they both don't expect their mid-layer runtime PM callbacks to > be invoked during system-wide suspend and resume. > > Patch [1/9] is a preparatory cleanup changing the code to use 'true' and > 'false' as needs_force_resume flag values for consistency." > > Patch [2/9] (which was [3/9] in v2) puts pm_runtime_force_resume() and one > other function that is only used during system sleep transitions under > CONFIG_PM_SLEEP. > > Patch [3/9] (which was [5/9] in v2) causes the smart_suspend flag to be taken > into account by pm_runtime_force_resume() which allows it to resume devices > with smart_suspend set whose runtime PM status has been changed to RPM_ACTIVE > by the PM core at the beginning of system resume. After this patch, drivers > that use pm_runtime_force_suspend/resume() can also set DPM_FLAG_SMART_SUSPEND > which may be useful, for example, if devices handled by them are involved in > dependency chains with other devices setting DPM_FLAG_SMART_SUSPEND. > > Since patches [1,3/9] have been reviewed already and patch [2/9] should not > be particularly controversial, I think that patches [1-3/9] are good to go. > > Patch [4/9] (which was [2/9] in v2), makes pm_runtime_reinit() clear > needs_force_resume in case it was set during driver remove. > > Patch [5/9] (which was [4/9] in v2) makes pm_runtime_force_suspend() check > needs_force_resume along with the device's runtime PM status upfront, and bail > out if it is set, which allows runtime PM status updates to be eliminated from > both that function and pm_runtime_force_resume(). I recalled too late that > it was actually necessary for the PCI PM and ACPI PM to work with > pm_runtime_force_suspend() correctly after the subsequent changes and that > patch [3/9] did not depend on it. I have also realized that patch [5/9] > potentially unbreaks drivers that call pm_runtime_force_suspend() from their > "remove" callbacks (see the patch changelog for a bit of an explanation). > > Patch [6/9] (which has not been changed since v2) makes the code for getting a > runtime PM callback for a device a bit more straightforward, in preparation for > the subsequent changes. > > Patch [7/9] introduces a new device PM flag called strict_midlayer that > can be set by middle layer code which doesn't want its runtime PM > callbacks to be used during system-wide PM transitions, like the PCI bus > type and the ACPI PM domain, and updates pm_runtime_force_suspend/resume() > to take that flag into account. Its changelog has been updated since v2 and > there is a new kerneldoc comment for dev_pm_set_strict_midlayer(). > > Patch [8/9] modifies the ACPI PM "prepare" and "complete" callback functions, > used by the general ACPI PM domain and by the ACPI LPSS PM domain, to set and > clear strict_midlayer, respectively, which allows drivers collaborating with it > to use pm_runtime_force_suspend/resume(). The changelog of this patch has been > made a bit more precise since v2. > > That may be useful if such a driver wants to be able to work with different > PM domains on different systems. It may want to work with the general ACPI PM > domain on systems using ACPI, or with another PM domain (or even multiple PM > domains at the same time) on systems without ACPI, and it may want to use > pm_runtime_force_suspend/resume() as its system-wide PM callbacks. > > Patch [9/9] updates the PCI bus type to set and clear, respectively, strict_midlayer > for all PCI devices in its "prepare" and "complete" PM callbacks, in case some > PCI drivers want to use pm_runtime_force_suspend/resume() in the future. They > will still need to set DPM_FLAG_SMART_SUSPEND to avoid resuming their devices during > system suspend, but now they may also use pm_runtime_force_suspend/resume() as > suspend callbacks for the "regular suspend" phase of device suspend (or invoke > these functions from their suspend callbacks). The changelog of this patch has > been made a bit more precise since v2, like the changelog of patch [8/9]. > > As usual, please refer to individual patch changelogs for more details. > > Thanks! > For the v3 series, please add: Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> Kind regards Uffe
