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

[Brian Norris <briannorris@chromium.org>]

(Note to self: drop linux-stm32@st-md-mailman.stormreply.com from future
postings. It's failing hard, and not (AFAICT) just because I'm not
subscribed.) 

On Mon, Oct 12, 2026 at 10:58:24PM +0300, Andy Shevchenko wrote:
> 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.

Well, it's not 20; it's 1, with a clear reason. So not sure what you're
saying. Anyway, I've prepped that for v2.

Do you think you could propose a documentation update, if it's really so
out-of-date with current practice?

FWIW, a quick look at the v7.1..v7.2 git log shows over 10,000 Cc lines
that aren't for stable@ or similar, with over 900 different addressees,
across roughly 1300 different commits. (For comparison, there are 17,833
commits in v7.1..v7.2.)

It seems like you'll have a hard job trying to apply your rule to
everybody's changes, especially if it conflicts with the documentation.

> > > > 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?

OK, I've tried to factor that into my drafts for an eventual v2.

Thanks!

Brian