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

[Andy Shevchenko]

On Mon, Oct 12, 2026 at 04:17:15PM -0700, Brian Norris wrote:
> 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 at 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.

Yes, I aware of that — "having one might not lead to the issue".

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

I posted some a few months ago, when I pointed out to that noise in the commit
messages, it was like a pushback, but since that I have convinced several
developers to follow, so it might be worth to try again (but it should not be
insisting, just a recommendation). Also note, that even in the cited piece
there is no clear point where to put that Cc tag. It's only required for
stable backporting process to be in the commit message, otherwise that tag
may well be located after the '---' line which still makes it a (email)
tag, but visible in the commit message.

> 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.)

Have you checked in dynamics? (Note, most of those Cc comes from Andrew
Morton's scripts and TIP tree.)

I used this:

$ git log --no-merges --grep '^Cc:' --pretty="%(trailers:key=Cc)" v<$A>..v<$B> | grep -v '^$' | grep -v 'stable at vger.kernel.org' | grep -v stable.*@kernel.org | wc -l

where <$A> and <$B> give a range.

v6.19..v7.0: 11525
v7.0..v7.1: 11594
v7.1..v7.2: 10946
v7.2..v7.3-rc7: 8696

You see, it works!

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

As I explained above it doesn't really conflict, it rather old established
process when people want to have that Cc be recorded, now we have
lore.kernel.org for that and I successfully convinced several people to follow.

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

-- 
With Best Regards,
Andy Shevchenko