Subject: Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree

From: "Luca Ceresoli" <[email-masked]>
Date: Wed, 18 Mar 2026 16:49:42 +0100

Hello Mark, all,

On Wed Mar 18, 2026 at 3:36 PM CET, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
>
> between commit:
>
>   cffcb42c57686 ("drm/bridge: dw-hdmi-qp: fix multi-channel audio output")
>
> from the drm-misc-fixes tree and commit:
>
>   3ea699b56d31c ("drm/bridge: dw-hdmi-qp: Rework Audio InfoFrame handler")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The conflict originated as I applied cffcb42c57686 on drm-misc-fixes. I
carefully followed the dim procedure as I know it, so I'm not sure I did
anything wrong, but if I did I apologize.

The steps I did are:

 - dim update-branches
 - dim checkout drm-misc-fixes
 - dim b4-shazam URL
 - dim checkpatch+sparse ...
 - dim push-branch drm-misc-fixes

One thing with this procedure is that dim push-branch pushes first, then
finds out any conflicts. I wonder whether dim could be changed to find any
conflicts before pushing.

As soon as dim push-branch warned me about the conflict I tried solving it
myself as per [0], but the patches on drm-misc-next (3ea699b56d31c) changed
the codebase completely and was unable to sort it out fully.

I at least fixed the conflict at a pure patch application level, so I would
expect the rerere cache would avoid future conflicts.  I was wrong
apparently. It had worked in the past, no idea what went wrong this time.

Then, as far as the original bug is concerned, I notified the involved
patch authors [1] hoping they could find out whether there is the same bug
in the drm-misc-next code and fix it if needed.

If there is anything I should have done differently I'd be happy to know in
order to adjust my process in the future.

[0] https://drm.pages.freedesktop.org/maintainer-tools/committer/conflict-resolution.html
[1] https://lore.kernel.org/lkml/[email-masked]/

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com