On Thu, Jun 26, 2025 at 12:05 PM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On Thu, 26 Jun 2025 at 11:41, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > On Thu, Jun 26, 2025 at 11:38 AM Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > > > On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > > > > > > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > > > > > Since pm_runtime_force_suspend/resume() and pm_runtime_need_not_resume() > > > > are only used during system-wide PM transitions, there is no reason to > > > > compile them in if CONFIG_PM_SLEEP is unset. > > > > > > > > Accordingly, move them all under CONFIG_PM_SLEEP and make the static > > > > inline stubs for pm_runtime_force_suspend/resume() return an error > > > > to indicate that they should not be used outside CONFIG_PM_SLEEP. > > > > > > > > > > Just realized that there seems to be some drivers that actually make > > > use of pm_runtime_force_suspend() from their ->remove() callbacks. > > > > > > To not break them, we probably need to leave this code to stay under CONFIG_PM. > > > > OK, pm_runtime_force_suspend() need not be under CONFIG_PM_SLEEP. > > That's not the case for the other two functions though AFAICS. > > Right, but maybe better to keep them to avoid confusion? There really is no point holding pm_runtime_need_not_resume() outside CONFIG_PM_SLEEP and pm_runtime_force_resume() really should not be used anywhere outside system resume flows. > At least the corresponding flag is needed. What flag do you mean? If pm_runtime_force_suspend() does not go under CONFIG_PM_SLEEP, needs_force_resume will not go under it either (so I'll drop the next patch altogether). Cheers, Rafael
