Re: [PATCH] resource, kunit: add dependency on SPARSEMEM

From: Guenter Roeck
Date: Sat Oct 12 2024 - 05:36:45 EST


On 10/11/24 20:43, Huang, Ying wrote:
Guenter Roeck <linux@xxxxxxxxxxxx> writes:

On 10/9/24 23:40, Huang, Ying wrote:
Hi, Guenter,
Guenter Roeck <linux@xxxxxxxxxxxx> writes:

On 9/23/24 18:21, Huang, Ying wrote:
Guenter Roeck <linux@xxxxxxxxxxxx> writes:

On 9/23/24 05:58, Geert Uytterhoeven wrote:
Hi Günter,
On Mon, Sep 23, 2024 at 12:50 AM Guenter Roeck <linux@xxxxxxxxxxxx>
wrote:
Building allmodconfig images on systems with SPARSEMEM=n results in
the following message.

WARNING: unmet direct dependencies detected for GET_FREE_REGION
Depends on [n]: SPARSEMEM [=n]
Selected by [m]:
- RESOURCE_KUNIT_TEST [=m] && RUNTIME_TESTING_MENU [=y] && KUNIT [=m]

and the build ultimately fails.
Really? What's the build error?

I saw it on hexagon, and I didn't bother writing down the actual build error
message. But it turns out you are correct, the m68k machine does build with
CONFIG_RESOURCE_KUNIT_TEST=y even though SPARSEMEM and with it GET_FREE_REGION
are not set. Never mind, I don't really want or have time to argue. I'll just
disable CONFIG_RESOURCE_KUNIT_TEST when building hexagon images and wherever
else I see the problem.

It does build for me on m68k, after fixing:
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -101,7 +101,7 @@ extern int mmap_rnd_compat_bits __read_mostly;
# ifdef MAX_PHYSMEM_BITS
# define PHYSMEM_END ((1ULL << MAX_PHYSMEM_BITS) - 1)
# else
-# define PHYSMEM_END (-1ULL)
+# define PHYSMEM_END ((phys_addr_t)-1)
# endif
#endif
After Linus' fix for PHYSMEM_END, GET_FREE_REGION doesn't need to
depend
on SPARSEMEM anymore. So, I think we can remove the dependency. Can
you check whether the following patch work for you on top of latest
upstream kernel (with Linus' fix).


It works for m68k. I'll run a complete test on all architectures/platforms
tonight.
Does it work in the complete test?


Sorry, I dropped that one. Yes, it does.


Thanks a lot! Can I add your Tested-by in the formal version?


Sure, go ahead.

Tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>

Guenter