Re: [v2,0/2] media: renesas: vsp1: Fix display pipeline regression

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, May 07, 2026 at 10:38:33AM +0200, Ricardo Ribalda wrote:
> On Thu, 7 May 2026 at 10:18, Laurent Pinchart wrote:
> > On Thu, May 07, 2026 at 07:30:43AM +0200, Ricardo Ribalda wrote:
> > > On Thu, 7 May 2026 at 01:11, Laurent Pinchart wrote:
> > > > On Wed, May 06, 2026 at 03:59:20PM -0700, Patchwork Integration wrote:
> > > > > Dear Laurent Pinchart:
> > > > >
> > > > > Thanks for your patches! Unfortunately the Media CI robot detected some
> > > > > issues:
> > > > >
> > > > > # Test media-patchstyle:./0001-Revert-media-renesas-vsp1-Initialize-format-on-all-p.patch media style
> > > > > ERROR: ./0001-Revert-media-renesas-vsp1-Initialize-format-on-all-p.patch: Missing committer Ricardo Ribalda <ribalda@chromium.org> Signed-off-by
> > > > > ERROR: Commit 133ac42af0a1b389e8b7b3dc7c1cc8c30ff162b6 found in the stable tree, but stable@vger.kernel.org not in Cc:
> > > > >
> > > > > # Test media-patchstyle:./0002-Revert-media-renesas-vsp1-brx-Fix-format-propagation.patch media style
> > > > > ERROR: ./0002-Revert-media-renesas-vsp1-brx-Fix-format-propagation.patch: Missing committer Ricardo Ribalda <ribalda@chromium.org> Signed-off-by
> > > >
> > > > I'm not going to add your SoB to my patches :-)
> > >
> > > You did not get the memo. From now on, all patches in the kernel need
> > > to be SoB my me :P
> > >
> > > Sorry about that, Yesterday I had to recreate the local repo and
> > > forgot to set the proper committer. It should be fixed now.
> > >
> > > > > ERROR: Commit 937f3e6b51f1cea079be9ba642665f2bf8bcc31f found in the stable tree, but stable@vger.kernel.org not in Cc:
> > > >
> > > > I don't see these commits in any of the stable branches. Does the
> > > > message mean the mainline tree, not the stable tree ?
> > >
> > > It means the stable tree
> > >
> > > ribalda@ribalda:~/work/linux$ git fetch
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> > > 937f3e6b51f1cea079be9ba642665f2bf8bcc31f
> > > From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux
> > >  * branch
> > > 937f3e6b51f1cea079be9ba642665f2bf8bcc31f -> FETCH_HEAD
> >
> > Ah right. But I don't think that's relevant. The commit is from the
> > master branch of the stable tree, which simply mirrors Linus' tree. It's
> > not in any stable branch.
> >
> > $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git stable
> > Cloning into 'stable'...
> > [...]
> > laurent@killaraus ~/src/kernel $ cd stable
> > laurent@killaraus ~/src/kernel/stable $ git branch -a --contains 937f3e6b51f1cea079be9ba642665f2bf8bcc31f
> > * master
> >   remotes/origin/HEAD -> origin/master
> >   remotes/origin/master
> > laurent@killaraus ~/src/kernel/stable $ git tag --contains 937f3e6b51f1cea079be9ba642665f2bf8bcc31f
> > v7.1-rc1
> > v7.1-rc2
> >
> > This means the commit hasn't been backported to stable, it has just been
> > merged to mainline.
> >
> > If the purpose of this is to check if the commit has been merged in
> > mainline, I think the message should refer to mainline. If it's to check
> > if it has been backported to a stable kernel, then those are false
> > positives.
> >
> > Note that commit ID change when they're backported. If you want to check
> > if a commit has been backported, you'll need to grep for
> >
> >     commit ${upstream_commit_id} upstream.
> >
> > in commit *messages* of all stable branches.
> >
> > > > Given that this series should be merged in v7.1 as a regression fix, why
> > > > should it CC stable ?
> > >
> > > Somehow that patch has been backported, so I guess it should cc stable.
> >
> > No, it hasn't been backported.
> 
> You are completely right. And we have been doing this wrong for a long time....
> 
> We have a challenge that it is not trivial to fix. The builder do not
> have a clone of linus-stable, it queries it with something similar to
> "git ls-remote". So I cannot use "git log | grep".
> 
> Ideally we could have a web server to check if a sha has been
> backported, but that does not exist yet. It could probably be a nice
> little vibecoding project.

You had me interested until I read vibecoding. /me walks out the door.

> The question right now is if it is best to disable the check
> completely or keep it and live with the false positives.
> 
> Need to check with my pillow.

Given that the check essentially flags any patch that Fixes: a commit
present in mainline, I don't think we should keep it in its current
form. If desired, we could replace it with a check that flags Fixes:
without CC: stable, unconditionally. I think that's too strict though,
so it would need to be a warning that wouldn't block merging.

> > > > > Please fix your series, and upload a new version. If you have a patchwork
> > > > > account, do not forget to mark the current series as Superseded.
> > > > >
> > > > > For more details, check the full report at:
> > > > > https://linux-media.pages.freedesktop.org/-/users/patchwork/-/jobs/99198847/artifacts/report.htm .
> > > > >
> > > > >
> > > > >
> > > > > Best regards, and Happy Hacking!
> > > > > Media CI robot on behalf of the linux-media community.
> > > > >
> > > > > ---
> > > > > Check the latest rules for contributing your patches at:
> > > > > https://docs.kernel.org/driver-api/media/maintainer-entry-profile.html
> > > > >
> > > > > If you believe that the CI is wrong, kindly open an issue at
> > > > > https://gitlab.freedesktop.org/linux-media/media-ci/-/issues or reply-all
> > > > > to this message.

-- 
Regards,

Laurent Pinchart