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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

Hi all,

After merging the drm-xe tree, today's linux-next build (arm64 defconfig)
failed like this:

arch/arm64/kvm/hyp/nvhe/hyp-init.S: Assembler messages:
arch/arm64/kvm/hyp/nvhe/hyp-init.S:557: Error: found 'l', expected: ')'
arch/arm64/kvm/hyp/nvhe/hyp-init.S:29:  Info: macro invoked from here
arch/arm64/kvm/hyp/nvhe/hyp-init.S:221:   Info: macro invoked from here
arch/arm64/kvm/hyp/nvhe/hyp-init.S:557: Error: non-constant expression in ".if" statement
arch/arm64/kvm/hyp/nvhe/hyp-init.S:557: Error: junk at end of line, first unrecognized character is `l'
arch/arm64/kvm/hyp/nvhe/hyp-init.S:560: Error: found 'l', expected: ')'
arch/arm64/kvm/hyp/nvhe/hyp-init.S:560: Error: non-constant expression in ".if" statement
arch/arm64/kvm/hyp/nvhe/hyp-init.S:560: Error: junk at end of line, first unrecognized character is `l'

and many, many more.

Bisected to commit

  b77cb9640f1f ("bits: introduce fixed-type genmasks")

I have reverted that commit (and the following 2) for today.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Lucas De Marchi]

On Thu, Feb 22, 2024 at 07:04:48PM +1100, Stephen Rothwell wrote:
>Hi all,
>
>After merging the drm-xe tree, today's linux-next build (arm64 defconfig)
>failed like this:
>
>arch/arm64/kvm/hyp/nvhe/hyp-init.S: Assembler messages:
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:557: Error: found 'l', expected: ')'
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:29:  Info: macro invoked from here
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:221:   Info: macro invoked from here
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:557: Error: non-constant expression in ".if" statement
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:557: Error: junk at end of line, first unrecognized character is `l'
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:560: Error: found 'l', expected: ')'
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:560: Error: non-constant expression in ".if" statement
>arch/arm64/kvm/hyp/nvhe/hyp-init.S:560: Error: junk at end of line, first unrecognized character is `l'
>
>and many, many more.
>
>Bisected to commit
>
>  b77cb9640f1f ("bits: introduce fixed-type genmasks")
>
>I have reverted that commit (and the following 2) for today.

those commits were already removed from our branch due to those issues.
New fixed version of them should appear through the new bitmap tree
maintained by Yury.

Sorry for the noise they caused and thanks.

Lucas De Marchi

>
>-- 
>Cheers,
>Stephen Rothwell

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]

Hi all,

After merging the drm-xe tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/xe/display/xe_display.c: In function 'xe_display_pm_shutdown':
drivers/gpu/drm/xe/display/xe_display.c:382:27: error: passing argument 1 of 'intel_dmc_suspend' from incompatible pointer type [-Wincompatible-pointer-types]
  382 |         intel_dmc_suspend(xe);
      |                           ^~
      |                           |
      |                           struct xe_device *
In file included from drivers/gpu/drm/xe/display/xe_display.c:24:
drivers/gpu/drm/i915/display/intel_dmc.h:22:46: note: expected 'struct intel_display *' but argument is of type 'struct xe_device *'
   22 | void intel_dmc_suspend(struct intel_display *display);
      |                        ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~

Caused by commit

  501d799a47e2 ("drm/xe: Wire up device shutdown handler")

interacting with commit

  5c30cfa295cc ("drm/i915/dmc: Convert DMC code to intel_display")

from the drm-intel tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 1 Oct 2024 11:30:00 +1000
Subject: [PATCH] fix up for "drm/xe: Wire up device shutdown handler"

interacting with commit

  5c30cfa295cc ("drm/i915/dmc: Convert DMC code to intel_display")

from the drm-intel tree.
---
 drivers/gpu/drm/xe/display/xe_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/display/xe_display.c b/drivers/gpu/drm/xe/display/xe_display.c
index 957ae763531d..ca00a365080f 100644
--- a/drivers/gpu/drm/xe/display/xe_display.c
+++ b/drivers/gpu/drm/xe/display/xe_display.c
@@ -379,7 +379,7 @@ void xe_display_pm_shutdown(struct xe_device *xe)
 
 	intel_opregion_suspend(display, PCI_D3cold);
 
-	intel_dmc_suspend(xe);
+	intel_dmc_suspend(display);
 }
 
 void xe_display_pm_runtime_suspend(struct xe_device *xe)
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

Hi all,

After merging the drm-xe tree, today's linux-next build (x86
allmodconfig) failed like this:

In file included from /tmp/next/build/include/linux/module.h:22,
                 from /tmp/next/build/include/linux/device/driver.h:21,
                 from /tmp/next/build/include/linux/device.h:32,
                 from /tmp/next/build/include/linux/auxiliary_bus.h:11,
                 from /tmp/next/build/include/linux/intel_vsec.h:5,
                 from /tmp/next/build/drivers/gpu/drm/xe/xe_vsec.c:7:
/tmp/next/build/drivers/gpu/drm/xe/xe_vsec.c:233:18: error: expected ',' or ';' before 'INTEL_VSEC'
  233 | MODULE_IMPORT_NS(INTEL_VSEC);
      |                  ^~~~~~~~~~
/tmp/next/build/include/linux/moduleparam.h:26:61: note: in definition of macro '__MODULE_INFO'
   26 |                 = __MODULE_INFO_PREFIX __stringify(tag) "=" info
      |                                                             ^~~~
/tmp/next/build/include/linux/module.h:299:33: note: in expansion of macro 'MODULE_INFO'
  299 | #define MODULE_IMPORT_NS(ns)    MODULE_INFO(import_ns, ns)
      |                                 ^~~~~~~~~~~
/tmp/next/build/drivers/gpu/drm/xe/xe_vsec.c:233:1: note: in expansion of macro 'MODULE_IMPORT_NS'
  233 | MODULE_IMPORT_NS(INTEL_VSEC);
      | ^~~~~~~~~~~~~~~~

You need to merge up cdd30ebb1b9f36159d66f088b61aee264e649d7a ("module:
Convert symbol namespace to string literal") from mainline and fix up
for the changes in MODULE_IMPORT_NS.  I'll apply a fixup for now.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jani Nikula]

On Wed, 04 Dec 2024, Mark Brown <broonie@kernel.org> wrote:
> Hi all,
>
> After merging the drm-xe tree, today's linux-next build (x86
> allmodconfig) failed like this:
>
> In file included from /tmp/next/build/include/linux/module.h:22,
>                  from /tmp/next/build/include/linux/device/driver.h:21,
>                  from /tmp/next/build/include/linux/device.h:32,
>                  from /tmp/next/build/include/linux/auxiliary_bus.h:11,
>                  from /tmp/next/build/include/linux/intel_vsec.h:5,
>                  from /tmp/next/build/drivers/gpu/drm/xe/xe_vsec.c:7:
> /tmp/next/build/drivers/gpu/drm/xe/xe_vsec.c:233:18: error: expected ',' or ';' before 'INTEL_VSEC'
>   233 | MODULE_IMPORT_NS(INTEL_VSEC);
>       |                  ^~~~~~~~~~
> /tmp/next/build/include/linux/moduleparam.h:26:61: note: in definition of macro '__MODULE_INFO'
>    26 |                 = __MODULE_INFO_PREFIX __stringify(tag) "=" info
>       |                                                             ^~~~
> /tmp/next/build/include/linux/module.h:299:33: note: in expansion of macro 'MODULE_INFO'
>   299 | #define MODULE_IMPORT_NS(ns)    MODULE_INFO(import_ns, ns)
>       |                                 ^~~~~~~~~~~
> /tmp/next/build/drivers/gpu/drm/xe/xe_vsec.c:233:1: note: in expansion of macro 'MODULE_IMPORT_NS'
>   233 | MODULE_IMPORT_NS(INTEL_VSEC);
>       | ^~~~~~~~~~~~~~~~
>
> You need to merge up cdd30ebb1b9f36159d66f088b61aee264e649d7a ("module:
> Convert symbol namespace to string literal") from mainline and fix up
> for the changes in MODULE_IMPORT_NS.  I'll apply a fixup for now.

Commit cdd30ebb1b9f ("module: Convert symbol namespace to string
literal") isn't even in a tagged release yet. We'll get it when -rc1 is
out *and* backmerged to drm-next.

BR,
Jani.

-- 
Jani Nikula, Intel

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Wed, Dec 04, 2024 at 03:46:21PM +0200, Jani Nikula wrote:
> On Wed, 04 Dec 2024, Mark Brown <broonie@kernel.org> wrote:

> > You need to merge up cdd30ebb1b9f36159d66f088b61aee264e649d7a ("module:
> > Convert symbol namespace to string literal") from mainline and fix up
> > for the changes in MODULE_IMPORT_NS.  I'll apply a fixup for now.

> Commit cdd30ebb1b9f ("module: Convert symbol namespace to string
> literal") isn't even in a tagged release yet. We'll get it when -rc1 is
> out *and* backmerged to drm-next.

Yes, it's very disruptive :(

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

Hi all,

After merging the drm-xe tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/drm_gpusvm.c: In function 'drm_gpusvm_range_get_pages':
drivers/gpu/drm/drm_gpusvm.c:1404:44: error: 'struct page' has no member named 'pgmap'
 1404 |                         if (pagemap != page->pgmap) {
      |                                            ^~
drivers/gpu/drm/drm_gpusvm.c:1410:47: error: 'struct page' has no member named 'pgmap'
 1410 |                                 pagemap = page->pgmap;
      |                                               ^~

Caused by commit

  99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")

interacting with commit

  089b22f60a0f ("mm: allow compound zone device pages")

from the mm-unstable branch of the mm tree.

I have applied the following merge fix patch for today.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 7 Mar 2025 12:48:32 +1100
Subject: [PATCH] fix up for "drm/gpusvm: Add support for GPU Shared Virtual
 Memory"

interacting with commit

  089b22f60a0f ("mm: allow compound zone device pages")

from the mm-unstable branch of the mm tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/drm_gpusvm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
index f314f5c4af0f..5e9b18ce65f8 100644
--- a/drivers/gpu/drm/drm_gpusvm.c
+++ b/drivers/gpu/drm/drm_gpusvm.c
@@ -1401,13 +1401,13 @@ int drm_gpusvm_range_get_pages(struct drm_gpusvm *gpusvm,
 				goto err_unmap;
 			}
 			zdd = page->zone_device_data;
-			if (pagemap != page->pgmap) {
+			if (pagemap != page_pgmap(page)) {
 				if (i > 0) {
 					err = -EOPNOTSUPP;
 					goto err_unmap;
 				}
 
-				pagemap = page->pgmap;
+				pagemap = page_pgmap(page);
 				dpagemap = zdd->devmem_allocation->dpagemap;
 				if (drm_WARN_ON(gpusvm->drm, !dpagemap)) {
 					/*
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 6028 bytes --]

Hi all,

After merging the drm-xe tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/kernel.h:22,
                 from include/linux/cpumask.h:11,
                 from arch/x86/include/asm/paravirt.h:21,
                 from arch/x86/include/asm/irqflags.h:80,
                 from include/linux/irqflags.h:18,
                 from include/linux/spinlock.h:59,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:7,
                 from include/linux/mm.h:7,
                 from include/linux/pagemap.h:8,
                 from include/drm/ttm/ttm_tt.h:30,
                 from drivers/gpu/drm/xe/xe_bo.h:9,
                 from drivers/gpu/drm/xe/xe_svm.c:6:
drivers/gpu/drm/xe/xe_svm.c: In function 'page_to_vr':
drivers/gpu/drm/xe/xe_svm.c:344:33: error: 'struct page' has no member named 'pgmap'
  344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
      |                                 ^~
include/linux/container_of.h:19:33: note: in definition of macro 'container_of'
   19 |         void *__mptr = (void *)(ptr);                                   \
      |                                 ^~~
In file included from include/linux/init.h:5,
                 from include/linux/printk.h:6,
                 from include/asm-generic/bug.h:22,
                 from arch/x86/include/asm/bug.h:99,
                 from include/linux/bug.h:5,
                 from include/linux/mmdebug.h:5,
                 from include/linux/mm.h:6:
drivers/gpu/drm/xe/xe_svm.c:344:33: error: 'struct page' has no member named 'pgmap'
  344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
      |                                 ^~
include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
   78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
      |                                                        ^~~~
include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
   20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
      |         ^~~~~~~~~~~~~
include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
   20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
      |                       ^~~~~~~~~~~
drivers/gpu/drm/xe/xe_svm.c:344:16: note: in expansion of macro 'container_of'
  344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
      |                ^~~~~~~~~~~~
drivers/gpu/drm/xe/xe_svm.c:344:33: error: 'struct page' has no member named 'pgmap'
  344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
      |                                 ^~
include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
   78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
      |                                                        ^~~~
include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
   20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
      |         ^~~~~~~~~~~~~
include/linux/container_of.h:21:23: note: in expansion of macro '__same_type'
   21 |                       __same_type(*(ptr), void),                        \
      |                       ^~~~~~~~~~~
drivers/gpu/drm/xe/xe_svm.c:344:16: note: in expansion of macro 'container_of'
  344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
      |                ^~~~~~~~~~~~
include/linux/compiler_types.h:483:27: error: expression in static assertion is not an integer
  483 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
   78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
      |                                                        ^~~~
include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
   20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
      |         ^~~~~~~~~~~~~
include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
   20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
      |                       ^~~~~~~~~~~
drivers/gpu/drm/xe/xe_svm.c:344:16: note: in expansion of macro 'container_of'
  344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
      |                ^~~~~~~~~~~~

Caused by commit

  11bbe0d9aa96 ("drm/xe: Add drm_pagemap ops to SVM")

interacting with commit

  089b22f60a0f ("mm: allow compound zone device pages")

from the mm-unstable branch of the mm tree.

I have applied the following merge fix patch for today

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 7 Mar 2025 13:14:37 +1100
Subject: [PATCH] fixup for "drm/xe: Add drm_pagemap ops to SVM"

  089b22f60a0f ("mm: allow compound zone device pages")

from the mm-unstable branch of the mm tree.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 drivers/gpu/drm/xe/xe_svm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
index 516898e99b26..3e829c87d7b4 100644
--- a/drivers/gpu/drm/xe/xe_svm.c
+++ b/drivers/gpu/drm/xe/xe_svm.c
@@ -341,7 +341,7 @@ static void xe_svm_garbage_collector_work_func(struct work_struct *w)
 
 static struct xe_vram_region *page_to_vr(struct page *page)
 {
-	return container_of(page->pgmap, struct xe_vram_region, pagemap);
+	return container_of(page_pgmap(page), struct xe_vram_region, pagemap);
 }
 
 static struct xe_tile *vr_to_tile(struct xe_vram_region *vr)
-- 
2.45.2

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]

Hi all,

On Fri, 7 Mar 2025 12:58:03 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the drm-xe tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/drm_gpusvm.c: In function 'drm_gpusvm_range_get_pages':
> drivers/gpu/drm/drm_gpusvm.c:1404:44: error: 'struct page' has no member named 'pgmap'
>  1404 |                         if (pagemap != page->pgmap) {
>       |                                            ^~
> drivers/gpu/drm/drm_gpusvm.c:1410:47: error: 'struct page' has no member named 'pgmap'
>  1410 |                                 pagemap = page->pgmap;
>       |                                               ^~
> 
> Caused by commit
> 
>   99624bdff867 ("drm/gpusvm: Add support for GPU Shared Virtual Memory")
> 
> interacting with commit
> 
>   089b22f60a0f ("mm: allow compound zone device pages")
> 
> from the mm-unstable branch of the mm tree.
> 
> I have applied the following merge fix patch for today.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 7 Mar 2025 12:48:32 +1100
> Subject: [PATCH] fix up for "drm/gpusvm: Add support for GPU Shared Virtual
>  Memory"
> 
> interacting with commit
> 
>   089b22f60a0f ("mm: allow compound zone device pages")
> 
> from the mm-unstable branch of the mm tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/gpu/drm/drm_gpusvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> index f314f5c4af0f..5e9b18ce65f8 100644
> --- a/drivers/gpu/drm/drm_gpusvm.c
> +++ b/drivers/gpu/drm/drm_gpusvm.c
> @@ -1401,13 +1401,13 @@ int drm_gpusvm_range_get_pages(struct drm_gpusvm *gpusvm,
>  				goto err_unmap;
>  			}
>  			zdd = page->zone_device_data;
> -			if (pagemap != page->pgmap) {
> +			if (pagemap != page_pgmap(page)) {
>  				if (i > 0) {
>  					err = -EOPNOTSUPP;
>  					goto err_unmap;
>  				}
>  
> -				pagemap = page->pgmap;
> +				pagemap = page_pgmap(page);
>  				dpagemap = zdd->devmem_allocation->dpagemap;
>  				if (drm_WARN_ON(gpusvm->drm, !dpagemap)) {
>  					/*
> -- 
> 2.45.2

This is now a semantic conflict between the mm tree and the drm tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 6437 bytes --]

Hi Stephen,

On Fri, 7 Mar 2025 13:21:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> After merging the drm-xe tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/kernel.h:22,
>                  from include/linux/cpumask.h:11,
>                  from arch/x86/include/asm/paravirt.h:21,
>                  from arch/x86/include/asm/irqflags.h:80,
>                  from include/linux/irqflags.h:18,
>                  from include/linux/spinlock.h:59,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:7,
>                  from include/linux/mm.h:7,
>                  from include/linux/pagemap.h:8,
>                  from include/drm/ttm/ttm_tt.h:30,
>                  from drivers/gpu/drm/xe/xe_bo.h:9,
>                  from drivers/gpu/drm/xe/xe_svm.c:6:
> drivers/gpu/drm/xe/xe_svm.c: In function 'page_to_vr':
> drivers/gpu/drm/xe/xe_svm.c:344:33: error: 'struct page' has no member named 'pgmap'
>   344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
>       |                                 ^~
> include/linux/container_of.h:19:33: note: in definition of macro 'container_of'
>    19 |         void *__mptr = (void *)(ptr);                                   \
>       |                                 ^~~
> In file included from include/linux/init.h:5,
>                  from include/linux/printk.h:6,
>                  from include/asm-generic/bug.h:22,
>                  from arch/x86/include/asm/bug.h:99,
>                  from include/linux/bug.h:5,
>                  from include/linux/mmdebug.h:5,
>                  from include/linux/mm.h:6:
> drivers/gpu/drm/xe/xe_svm.c:344:33: error: 'struct page' has no member named 'pgmap'
>   344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
>       |                                 ^~
> include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
>    78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>       |                                                        ^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
>    20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
>       |         ^~~~~~~~~~~~~
> include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
>    20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
>       |                       ^~~~~~~~~~~
> drivers/gpu/drm/xe/xe_svm.c:344:16: note: in expansion of macro 'container_of'
>   344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
>       |                ^~~~~~~~~~~~
> drivers/gpu/drm/xe/xe_svm.c:344:33: error: 'struct page' has no member named 'pgmap'
>   344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
>       |                                 ^~
> include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
>    78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>       |                                                        ^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
>    20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
>       |         ^~~~~~~~~~~~~
> include/linux/container_of.h:21:23: note: in expansion of macro '__same_type'
>    21 |                       __same_type(*(ptr), void),                        \
>       |                       ^~~~~~~~~~~
> drivers/gpu/drm/xe/xe_svm.c:344:16: note: in expansion of macro 'container_of'
>   344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
>       |                ^~~~~~~~~~~~
> include/linux/compiler_types.h:483:27: error: expression in static assertion is not an integer
>   483 | #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
>       |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/build_bug.h:78:56: note: in definition of macro '__static_assert'
>    78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>       |                                                        ^~~~
> include/linux/container_of.h:20:9: note: in expansion of macro 'static_assert'
>    20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
>       |         ^~~~~~~~~~~~~
> include/linux/container_of.h:20:23: note: in expansion of macro '__same_type'
>    20 |         static_assert(__same_type(*(ptr), ((type *)0)->member) ||       \
>       |                       ^~~~~~~~~~~
> drivers/gpu/drm/xe/xe_svm.c:344:16: note: in expansion of macro 'container_of'
>   344 |         return container_of(page->pgmap, struct xe_vram_region, pagemap);
>       |                ^~~~~~~~~~~~
> 
> Caused by commit
> 
>   11bbe0d9aa96 ("drm/xe: Add drm_pagemap ops to SVM")
> 
> interacting with commit
> 
>   089b22f60a0f ("mm: allow compound zone device pages")
> 
> from the mm-unstable branch of the mm tree.
> 
> I have applied the following merge fix patch for today
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 7 Mar 2025 13:14:37 +1100
> Subject: [PATCH] fixup for "drm/xe: Add drm_pagemap ops to SVM"
> 
>   089b22f60a0f ("mm: allow compound zone device pages")
> 
> from the mm-unstable branch of the mm tree.
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  drivers/gpu/drm/xe/xe_svm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> index 516898e99b26..3e829c87d7b4 100644
> --- a/drivers/gpu/drm/xe/xe_svm.c
> +++ b/drivers/gpu/drm/xe/xe_svm.c
> @@ -341,7 +341,7 @@ static void xe_svm_garbage_collector_work_func(struct work_struct *w)
>  
>  static struct xe_vram_region *page_to_vr(struct page *page)
>  {
> -	return container_of(page->pgmap, struct xe_vram_region, pagemap);
> +	return container_of(page_pgmap(page), struct xe_vram_region, pagemap);
>  }
>  
>  static struct xe_tile *vr_to_tile(struct xe_vram_region *vr)
> -- 
> 2.45.2

This is now a semantic conflict between the mm tree and the drm tree.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Souza, Jose]

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?

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.

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

[Rodrigo Vivi]

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?


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

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

[Souza, Jose]

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.

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

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

[Rodrigo Vivi]

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?

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

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

[Lionel Landwerlin]

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?


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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Rodrigo Vivi]

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

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

[Rodrigo Vivi]

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.

Sorry,
Rodrigo.

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

[Souza, Jose]

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

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Thu, Mar 12, 2026 at 08:50:53PM -0400, Rodrigo Vivi wrote:
> On Thu, Mar 12, 2026 at 11:43:40AM +0000, Mark Brown wrote:

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

That also works.

> The pull-requests are already happening, so we should be back in sync soon,
> then you can re-enable the branch.

To be clear when there's a build failure I don't remove branches, I
merge whatever the last version that worked was.  This means that every
day the merge has to try the build, see that it failed, then I have to
tell it to merge the old version, watch that get retried and then carry
on with the merge.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jani Nikula]

On Thu, 12 Mar 2026, Lionel Landwerlin <lionel.g.landwerlin@intel.com> wrote:
> Is there no process to deal with kind of merge issues quickly?

For us the main part of the process is: If the patch doesn't build after
applying, talk to the maintainers to get the merges and backmerges going
*before* pushing, *not* after.

Similar to linux-next, drm-tip is the early signal there's a
conflict. If you develop on top of drm-tip, you'll find out about the
conflicts when applying to the individual branches.

I'll try to get a drm-intel-next pull request going today, or Monday at
the latest. Lots of changelog to write. Then it's drm-intel-next ->
drm-next -> drm-xe-next merges/backmerges that need to happen.


BR,
Jani.


-- 
Jani Nikula, Intel

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

On Fri, Mar 13, 2026 at 03:57:12PM +0200, Jani Nikula wrote:
> On Thu, 12 Mar 2026, Lionel Landwerlin <lionel.g.landwerlin@intel.com> wrote:
> > Is there no process to deal with kind of merge issues quickly?

> For us the main part of the process is: If the patch doesn't build after
> applying, talk to the maintainers to get the merges and backmerges going
> *before* pushing, *not* after.

> Similar to linux-next, drm-tip is the early signal there's a
> conflict. If you develop on top of drm-tip, you'll find out about the
> conflicts when applying to the individual branches.

> I'll try to get a drm-intel-next pull request going today, or Monday at
> the latest. Lots of changelog to write. Then it's drm-intel-next ->
> drm-next -> drm-xe-next merges/backmerges that need to happen.

Any news on this?  We now have issues with the main drm tree interacting
with drm-intel due to this change.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Jani Nikula]

On Mon, 16 Mar 2026, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Mar 13, 2026 at 03:57:12PM +0200, Jani Nikula wrote:
>> On Thu, 12 Mar 2026, Lionel Landwerlin <lionel.g.landwerlin@intel.com> wrote:
>> > Is there no process to deal with kind of merge issues quickly?
>
>> For us the main part of the process is: If the patch doesn't build after
>> applying, talk to the maintainers to get the merges and backmerges going
>> *before* pushing, *not* after.
>
>> Similar to linux-next, drm-tip is the early signal there's a
>> conflict. If you develop on top of drm-tip, you'll find out about the
>> conflicts when applying to the individual branches.
>
>> I'll try to get a drm-intel-next pull request going today, or Monday at
>> the latest. Lots of changelog to write. Then it's drm-intel-next ->
>> drm-next -> drm-xe-next merges/backmerges that need to happen.
>
> Any news on this?  We now have issues with the main drm tree interacting
> with drm-intel due to this change.

Matthew, please do the drm-intel -> drm-xe-next backmerge, and ensure
the merge commit builds.

BR,
Jani.


-- 
Jani Nikula, Intel

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

[Jani Nikula]

On Thu, 19 Mar 2026, Jani Nikula <jani.nikula@intel.com> wrote:
> On Mon, 16 Mar 2026, Mark Brown <broonie@kernel.org> wrote:
>> On Fri, Mar 13, 2026 at 03:57:12PM +0200, Jani Nikula wrote:
>>> On Thu, 12 Mar 2026, Lionel Landwerlin <lionel.g.landwerlin@intel.com> wrote:
>>> > Is there no process to deal with kind of merge issues quickly?
>>
>>> For us the main part of the process is: If the patch doesn't build after
>>> applying, talk to the maintainers to get the merges and backmerges going
>>> *before* pushing, *not* after.
>>
>>> Similar to linux-next, drm-tip is the early signal there's a
>>> conflict. If you develop on top of drm-tip, you'll find out about the
>>> conflicts when applying to the individual branches.
>>
>>> I'll try to get a drm-intel-next pull request going today, or Monday at
>>> the latest. Lots of changelog to write. Then it's drm-intel-next ->
>>> drm-next -> drm-xe-next merges/backmerges that need to happen.
>>
>> Any news on this?  We now have issues with the main drm tree interacting
>> with drm-intel due to this change.
>
> Matthew, please do the drm-intel -> drm-xe-next backmerge, and ensure
> the merge commit builds.

Argh, obviously drm-next -> drm-xe-next, *not* cross-merges between
Intel trees. *facepalm*.


-- 
Jani Nikula, Intel