Re: [PATCH v3 1/3] gpu/buddy: fix module_init() usage

[Joel Fernandes <joelagnelf@nvidia.com>]

> On Feb 20, 2026, at 5:17 AM, Danilo Krummrich <dakr@kernel.org> wrote:
> 
> On Fri Feb 20, 2026 at 7:06 AM CET, Greg KH wrote:
>>> On Thu, Feb 19, 2026 at 10:38:56PM +0100, Koen Koning wrote:
>>> Use subsys_initcall() instead of module_init() (which compiles to
>>> device_initcall() for built-ins) for buddy, so its initialization code
>>> always runs before any (built-in) drivers.
>>> This happened to work correctly so far due to the order of linking in
>>> the Makefiles, but this should not be relied upon.
>> 
>> Same here, Makefile order can always be relied on.
> 
> I want to point out that Koen's original patch fixed the Makefile order:
> 
> diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
> index 5cd54d06e262..b4e5e338efa2 100644
> --- a/drivers/gpu/Makefile
> +++ b/drivers/gpu/Makefile
> @@ -2,8 +2,9 @@
> # drm/tegra depends on host1x, so if both drivers are built-in care must be
> # taken to initialize them in the correct order. Link order is the only way
> # to ensure this currently.
> +# Similarly, buddy must come first since it is used by other drivers.
> +obj-$(CONFIG_GPU_BUDDY)    += buddy.o
> obj-y            += host1x/ drm/ vga/ tests/
> obj-$(CONFIG_IMX_IPUV3_CORE)    += ipu-v3/
> obj-$(CONFIG_TRACE_GPU_MEM)        += trace/
> obj-$(CONFIG_NOVA_CORE)        += nova-core/
> -obj-$(CONFIG_GPU_BUDDY)        += buddy.o
> 
> He was then suggested to not rely on this and rather use subsys_initcall().

I take the blame for the suggestion; however, I am not yet convinced it is a bad
idea. 
> 
> When I then came across the new patch using subsys_initcall() I made it worse; I
> badly confused this with something else and gave a wrong advise -- sorry Koen!
> 
> (Of course, since this is all within the same subsystem, without any external
> ordering contraints, Makefile order is sufficient.)

If we are still going to do the link ordering by reordering in the Makefile,
may I ask what is the drawback of doing the alternative - that is, not
relying on that (and its associated potential for breakage)?

Even if Makefile ordering can be relied on, why do we want to rely on it if
there is an alternative? Also module_init() compiles to device_initcall() for
built-ins and this is shared infra.

We use this technique in other code paths too, no? See
drivers/i2c/i2c-core-base.c:

  /* We must initialize early, because some subsystems register i2c drivers
   * in subsys_initcall() code, but are linked (and initialized) before i2c.
   */
  postcore_initcall(i2c_init);

If there is a drawback I am all ears but otherwise I would prefer the new
patch tbh. 

--
Joel Fernandes