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

From: Lionel Landwerlin <[email-masked]>
Date: Thu, 12 Mar 2026 09:47:26 +0200

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/49d[email-masked]/
>>>> 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?

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