drm/tests/drm_buddy: fix build failure on 32-bit targets

drm/tests/drm_buddy: fix build failure on 32-bit targets

Guenter Roeck reports that commit a64056bb5a32 ("drm/tests/drm_buddy:
add alloc_contiguous test") causes build failures on 32-bit targets:

 "This patch breaks the build on all 32-bit systems since it introduces
  an unhandled direct 64-bit divide operation.

  ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined!
  ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko] undefined!"

and the uses of 'u64' are all entirely pointless.  Yes, the arguments to
drm_buddy_init() and drm_buddy_alloc_blocks() are in fact of type 'u64',
but none of the values here are remotely relevant, and the compiler will
happily just do the type expansion.

Of course, in a perfect world the compiler would also have just noticed
that all the values in question are tiny, and range analysis would have
shown that doing a 64-bit divide is pointless, but that is admittedly
expecting a fair amount of the compiler.

IOW, we shouldn't write code that the compiler then has to notice is
unnecessarily complicated just to avoid extra work.  We do have fairly
high expectations of compilers, but kernel code should be reasonable to
begin with.

It turns out that there are also other issues with this code: the KUnit
assertion messages have incorrect types in the format strings, but
that's a widely spread issue caused by the KUnit infrastructure not
having enabled format string verification.  We'll get that sorted out
separately.

Reported-by: Guenter Roeck <linux@roeck-us.net>
Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
Link: https://lore.kernel.org/all/538327ff-8d34-41d5-a9ae-1a334744f5ae@roeck-us.net/
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>