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

["Souza, Jose" <jose.souza@intel.com>]

On Thu, 2026-03-12 at 20:50 -0400, Rodrigo Vivi wrote:
> On Thu, Mar 12, 2026 at 11:43:40AM +0000, Mark Brown wrote:
> > On Thu, Mar 12, 2026 at 09:47:26AM +0200, Lionel Landwerlin wrote:
> > > On 11/03/2026 22:11, Rodrigo Vivi wrote:
> > 
> > > > 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?
> > 
> > The usual thing that normal trees would do would be to make a
> > shared
> > branch with just the API change in it that all the affected trees
> > could
> > merge and base their ongoing work off.
> 
> We can work with topic branch as well, but the backmerge is not a
> hard process
> for us. We should just not have rushed with this patch to start with,
> then
> we could had put the branch in sync.
> 
> My apologies for not identifying earlier that this was the case here
> when I
> first tried to apply the patch. I wrongly assumed the patch was not
> based
> on the right branch...
> 
> The pull-requests are already happening, so we should be back in sync
> soon,
> then you can re-enable the branch.

Couldn't we simply define the new macro name as an alias for the old
one? We could then revert this change after the rebases are complete.

As Lionel pointed out, this macro mask is widely used within the Xe KMD
driver.
Without this bridge, any developer working on a patch using that mask
would be forced to delay their merge for several weeks.

> 
> Sorry,
> Rodrigo.
> 
> 
>