Re: linux-next: build failure after merge of the drm-xe tree

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Mar 12, 2026 at 09:47:26AM +0200, Lionel Landwerlin wrote:
> On 11/03/2026 22:11, Rodrigo Vivi wrote:
> > On Wed, Mar 11, 2026 at 02:16:22PM -0400, Souza, Jose wrote:
> > > On Wed, 2026-03-11 at 14:10 -0400, Rodrigo Vivi wrote:
> > > > On Wed, Mar 11, 2026 at 01:16:22PM -0400, Souza, Jose wrote:
> > > > > Hi Rodrigo, can you help me here?
> > > > > 
> > > > > I think this issue was because
> > > > > https://lore.kernel.org/all/49dc20448a12f3e03f5f8347540d167a281b8987.1772042022.git.jani.nikula@intel.com/
> > > > > was merged in drm-intel-next.
> > > > > 
> > > > > If it was splitted into a i915 and a Xe KMD patches and merged each
> > > > > to
> > > > > its own tree I think we would have avoided the issue.
> > > > > But I have not looked at that whole series to understand why that
> > > > > decision was made.
> > > > > 
> > > > > I don't know how to fix it, maybe rebase drm-xe-next on top of drm-
> > > > > intel-next and then a new commit fixing 0e07b16371b6e.
> > > > > Not sure what is the best option, can you help us here?
> > > > This explains why the patch was not applying cleanly.
> > > > This is the reason why we should never ever edit the patch directly
> > > > when merging.
> > > > 
> > > > If this is breaking the drm-tip build as well we should immediately
> > > > revert the
> > > > patch. But I'm considering this anyway.
> > > > 
> > > > The alternative to that is:
> > > > 
> > > > Jani needs to do a drm-intel-next Pull request towards drm-next.
> > > > Then Sima and Dave picks that up.
> > > > Then Brost do a backmerge fixing the build issue in the merge commit.
> > > > Once we fix it we let Mark know so the branch gets re-enabled in
> > > > linux-next.
> > > > 
> > > > Let's revert and re-attempt after drm-intel-next and drm-xe-next are
> > > > back in sync?
> > > drm-tip is not broken, Marteen fixed it in drm-rerere.
> > > 
> > > How long would it take to do this sync? If this is less than 30days I
> > > think we can revert and wait, if that is okay for Lionel that is
> > > working in the feature that depends on that patch.
> > We are in -rc3. Jani might be sending a PR in 2 weeks from now.
> > So, we might be in sync in 3 weeks. Worst case 30 days.
> > But it can be speed up with the help of the maintainers I mentioned.
> > 
> > Lionel, what do you think?
> 
> 
> Is there no process to deal with kind of merge issues quickly?
> 
> If someone comes along and changes the bitmask macros again, do we have to
> wait another month after that?

we should not had edited the patch while merging. That was the problem.
It should never had happen. It should never happen again!

> 
> 
> -Lionel
> 
> 
> > 
> > > > 
> > > > > Thank you
> > > > > 
> > > > > 
> > > > > On Wed, 2026-03-11 at 13:08 +0000, Mark Brown wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > After merging the drm-xe tree, today's linux-next build
> > > > > > (KCONFIG_NAME)
> > > > > > failed like this:
> > > > > > 
> > > > > > /tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c: In function
> > > > > > 'xe_lrc_ctx_init':
> > > > > > /tmp/next/build/drivers/gpu/drm/xe/xe_lrc.c:1554:43: error:
> > > > > > implicit
> > > > > > declaration of function '_MASKED_BIT_ENABLE'; did you mean
> > > > > > 'REG_MASKED_FIELD_ENABLE'? [-Wimplicit-function-declaration]
> > > > > >   1554 |                 state_cache_perf_fix[2] =
> > > > > > _MASKED_BIT_ENABLE(DISABLE_STATE_CACHE_PERF_FIX);
> > > > > >        |
> > > > > > ^~~~~~~~~~~~~~~~~~
> > > > > >        |
> > > > > > REG_MASKED_FIELD_ENABLE
> > > > > > 
> > > > > > Caused by commit
> > > > > > 
> > > > > >    0e07b16371b6e (drm/xe: Allow per queue programming of
> > > > > > COMMON_SLICE_CHICKEN3 bit13)
> > > > > > 
> > > > > > I have used the tree from next-20260310 instead.
> 
>