On 3/18/24 06:28, Lucas De Marchi wrote:
On Sun, Mar 17, 2024 at 09:14:14AM -0700, Guenter Roeck wrote:
Hi,
On Thu, Jan 18, 2024 at 04:16:12PM -0800, Lucas De Marchi wrote:
Now that all the issues with 32bits are fixed, enable it again.
Reviewed-by: Matt Roper <matthew.d.roper@xxxxxxxxx>
Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx>
---
drivers/gpu/drm/xe/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
index 1b57ae38210d..1b0ef91a5d2c 100644
--- a/drivers/gpu/drm/xe/Kconfig
+++ b/drivers/gpu/drm/xe/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_XE
tristate "Intel Xe Graphics"
- depends on DRM && PCI && MMU && (m || (y && KUNIT=y)) && 64BIT
+ depends on DRM && PCI && MMU && (m || (y && KUNIT=y))
I am curious about changes like this. Enabling 32-bit builds results in
build failures for mips_allmodconfig because the driver redefines END.
END is also used as macro in assembler code, the define happens to be
included for mips builds, and it would be difficult to change it there.
Unlike the i915 code, DRM_XE is not marked as depending on x86. This means
it will be built for pretty much all "allmodconfig" builds for all
architectures. Yet, there have been recent complaints about "allmodconfig"
builds of drm code causing build failures on "oddball" architectures.
Is there an assumption that DRM_XE (or DRM in general) is manually
excluded from all architectures where it fails to build ? If so, would
for all the reports we've been receiving we fixed the build and improved
CI to try to avoid the regressions. DRM_XE doesn't really depend on x86,
but I see your point of filtering out the "oddball architectures" or just
expose the ones we know it builds against. Yet, I don't see that
approach done in the wild in other drivers. At least on the build side, we
constantly check the reports from lkp like
https://lore.kernel.org/all/202403152008.KlwyYggO-lkp@xxxxxxxxx/
which also includes mips:
mips allnoconfig gcc
mips allyesconfig gcc
is that not sufficient? allyesconfig should be covering it afaics
FWIW: The kissb build system reports the problem as well, so it isn't
just me.
http://kisskb.ellerman.id.au/kisskb/buildresult/15143996/
Sure, that is allmodconfig vs. allyesconfig, but that does not make
a difference. The compiler version doesn't make a difference either.
kissb runs tests with gcc-8 and gcc-13, and they both fail.
Guenter
