Re: [GIT FIXE FOR 6.17] Drop redundant pm_runtime_mark_last_busy() and lt6911uxe fix

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Wed, 27 Aug 2025 13:14:18 +0300
Sakari Ailus <sakari.ailus@iki.fi> escreveu:

> Hi Mauro,
> 
> On Wed, Aug 27, 2025 at 11:05:28AM +0200, Mauro Carvalho Chehab wrote:
> > Em Wed, 13 Aug 2025 09:04:23 +0000
> > Sakari Ailus <sakari.ailus@iki.fi> escreveu:
> >   
> > > Hi Hans, Mauro,
> > > 
> > > Here are the patches to drop the redundant pm_runtime_mark_last_busy()
> > > calls in drivers and an lt6911uxe fix that should also be merged to 6.16.  
> > 
> > Please fix your description. The above is not clear and doesn't tell
> > the hole history.
> > 
> > In this specific case, I would expect the description to be
> > similar to this one:
> > 
> > 
> > 	Hi Hans, Mauro,
> > 
> > 	Please pull for:
> > 
> > 	  - drop the redundant pm_runtime_mark_last_busy() on rkvdec driver;
> > 	  - fix an error handling in probe at rkvdec driver;
> > 	  - fix an issue affecting lt6911uxe/lt6911uxc related to CSI-2
> > 	    GPIO pins at int3472.
> > 
> > 	The fix for lt6911uxe/lt6911uxc is against drivers/platform/x86/intel,
> > 	and contains an A-B from one of X86 PLATFORM DRIVERS maintainers.
> > 
> > We need to have those at the merge requests as well, as we're using them
> > to generate PR summaries.  
> 
> That sounds entirely reasonable. Still, isn't this kind of more detailed
> information already available on the patch subject lines? Could those be
> used instead? The message in the PR usually describes the patches with less
> detail.

It is available, but:

1. a short description helps reviewing the patchset;
2. If anyone uses the affected devices and have those bugs, the PR 
   summary is the only e-mail he needs to check before deciding to
   pick or not the series;
3. it is also used when maintainers send upstream PRs;
4. the upstream PR summary can also be used by distro packagers to
   detect if a sent patch fixes or not existing open bugs.

By not doing it, it means that people that could be using the hardware
will have more problems to get patches to addres their issues. 

It also means that maintainers need to open all the patches in
the series before sending a patches upstream to generate the PR description,
which doesn't scale, specially on a multi-committers scenario.

On this particular case, there was not much efforts, as this was a 
small series, but when sending a PR with hundreds of patches, not 
having proper descriptions is a nightmare for maintainers.

Thanks,
Mauro