[PATCH v2 3/5] PM: runtime: Propagate last_busy from dependent to dependency

[Alan Stern]

On Wed, Nov 11, 2026 at 08:42:31AM -0800, Brian Norris wrote:
> Hi Alan,
> 
> On Tue, Nov 10, 2026 at 10:47:59PM -0500, Alan Stern wrote:
> > So yes, in the current scheme a parent's inactivity period doesn't start 
> > until all its children are suspended (unless the ignore_children flag is 
> > set, but never mind that now).
> 
> But to be clear, that's not actually how runtime PM works today. It only
> works this way for the very small handful of drivers where the parent
> calls pm_runtime_mark_last_busy() in .runtime_idle(). I think several
> people have acknolwedged that this is a bit of a hack, or at least a
> missing feature in runtime PM, and probably should be extended more
> widely.

I have to agree; it seems like something we missed.  But then, I've 
always had something of a blind spot for pm_runtime_idle().  In fact, my 
overall impression has been that in practice, drivers relying on 
pm_runtime_idle() for anything nontrivial would be more or less mutually 
exclusive with drivers relying on autosuspend.  But of course, 
maintainers are free to do whatever they want.

> > The parent's autosuspend delay therefore 
> > should take into account the expected time before one of the children 
> > may have to be resumed, as well as the expected time before the parent 
> > itself may be asked to do something that doesn't involve any children.
> > (Note that if a device has more than one child, the expected time before 
> > any of its children will be resumed can be different from the expected 
> > time before any single particular child will be resumed.)
> 
> "Expected time before a child may have to resume": isn't that child
> last_busy + child delay?

No; that value is the expected time before the child may be 
autosuspended.  Not to mention that you're mixing up clock times 
(last_busy) with time intervals (time before).

>  So that expected time is already in the past by
> the time the child autosuspends.

You must have misunderstood what I wrote.  Think of it this way: Let's 
say the last remaining active child goes into runtime suspend at time T.  
Let's also say that the parent expects none of the children will need to 
resume until time T + D.  Is D sufficiently large to make it worthwhile 
for the parent to suspend and then resume?  If not, the parent should 
remain active.  If yes, the parent should autosuspend -- and the length 
of time the parent should wait before autosuspending is on the order of 
the value of D (let's call it D*) that corresponds to this crossover 
point.  Thus the parent's autosuspend delay should be set to D*, or 
something close to it, in order to achieve both objectives.

> My point here was that I think Rafael was overly concerned about
> precisely tuning parent autosuspend delays at the same time as changing
> the runtime PM core behavior. Yes, they clearly can be tuned in user
> space; but he was suggesting a phase-in / opt-in approach to this
> change, because it might harm system power if it's not re-tuned.

Is anybody really trying to tune precisely parent autosuspend delays?  
On what basis?  I'm doubtful that anyone is sufficiently serious about 
it to be annoyed at this PM core change (i.e., setting last_busy when a 
child suspends).

> > > At the same time, it makes it harder to reason about the runtime PM API
> > > surface -- because currently, .runtime_idle() is a primary reason that
> > > pm_runtime_put() and pm_runtime_put_autosuspend() are different.
> > 
> > I wouldn't put it that way.  My feeling is that pm_runtime_put() could 
> > be replaced by pm_runtime_put_autosuspend(), since they should behave 
> > identically for devices that don't use autosuspend.
> 
> Ah, but that's not actually true! pm_runtime_put_autosuspend() skips
> .runtime_idle(). It (semi)directly calls rpm_suspend().

Like I said above, a blind spot regarding pm_runtime_idle().  And/or an 
impression that a driver might want to use pm_runtime_idle() or 
autosuspend but not both.

Anyway, pm_runtime_put_autosuspend() could easily be modified to call 
pm_runtime_idle() before rpm_suspend() if the device doesn't use 
autosuspend.  That's not likely to bother anybody.

> I appreciate all the responses. One particular part I did have questions
> on, which I'll mostly copy/paste:
> 
> [Rafael:]
> > Now, let me acknowledge that some drivers evidently want rpm_idle() to
> > always set the autosuspend timer instead of suspending the device
> > right away.  That may be because of the "unwanted parent suspends"
> > problem at hand or for other reasons.
> 
> Do we have any idea what the "other reasons" could be? For example,
> because driver writers found it too difficult to find all the
> appropriate places to call pm_runtime_mark_last_busy()? (Does commit
> b3db492e8335 ("PM: runtime: Mark last busy stamp in
> pm_runtime_put_autosuspend()") help? Or should pm_runtime_put() behave
> similarly?)

I have no idea.  Outside the area where I mainly work, I don't know what 
sorts of things driver writers are doing.  If you know any people who 
are doing this, you should ask them directly.

> I see that USB is one of the subsystems where .runtime_idle() calls
> pm_runtime_mark_last_busy(), and I thought you (Alan) might have some
> more background on that.

I don't remember exactly why that was done, but probably it was meant to 
carry out the behavior we've been discussing (autosuspend delay should 
start when the device and all its children become idle).

Alan Stern