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

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Mon, Oct 05, 2026 at 11:05:28AM -0700, Brian Norris wrote:
> On Sat, Oct 03, 2026 at 06:21:44PM +0300, Andy Shevchenko wrote:
> > On Fri, Oct 02, 2026 at 04:03:07PM -0700, Brian Norris wrote:

...

> > > Cc: Ulf Hansson <ulfh@kernel.org>
> > 
> > Can go under the '---' cutter, so it won't pollute the commit message in the
> > Git history.
> 
> This is a well-documented convention.
> 
> Documentation/process/submitting-patches.rst
> 
>   If a person has had the opportunity to comment on a patch, but has not
>   provided such comments, you may optionally add a ``Cc:`` tag to the patch.
>   This tag documents that potentially interested parties have been included in
>   the discussion.
> 
> I'm directly referencing Ulf's suggestions (Link tag), so I'm also
> making it explicit that I'm CC'ing him.

This piece of the documentation was written long time ago before we have got
the kernel.org controlled mailing archives (now it's lore.kernel.org). I argue
that this piece is outdated and we need to look at all aspects of the commit
message. Perhaps having one might not lead to the issue, but exempli gratia 20
is. I still think it should be moved to under '---' to show the good example.

> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > 
> >  Cc: ...

...

> > > +/*
> > > + * Propagate last_busy timestamp from one device to another. This can, for
> > > + * example, prevent overactive suspend when a dependency's usage is primarily
> > > + * driven by one of its dependents.
> > > + */

^^^

> > But here you already have an outdated ones, no? Why is this not a problem?
> 
> The "target" device (a supplier or parent) can't suspend before this
> point, because the dependent device still holds a reference -- so an
> "outdated" last_busy is not relevant yet. The target last_busy *might*
> become relevant after this point, so this is the point at which it needs
> updated (propagated).
> 
> That's what I mean in the commit message by:
> 
>   propagate last_busy timestamps from a dependent device to its
>   dependencies any time it may allow a dependency to suspend -- i.e.,
>   when releasing a refcount for its parent or suppliers.
> 
> Please let me know if I should add some clarification somewhere --
> perhaps also in the comments here on rpm_propagate_last_busy()? Or if
> you see some other problem in the reasoning.

Perhaps a word to the top function comment?

-- 
With Best Regards,
Andy Shevchenko