[v3,5/5] drm/xe: Enable 32bits build

[Guenter Roeck]

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 at intel.com>
>>> Signed-off-by: Lucas De Marchi <lucas.demarchi at intel.com>
>>> ---
>>>  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@intel.com/
> 
> 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