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

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Feb 20, 2026 at 08:55:52AM -0500, Joel Fernandes wrote:
> > 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. 

The "problem" is that the init levels are very "coarse", and the link
order is very specific.  You can play with init levels a lot, but what
happens if another driver also sets to the same init level, or an
earlier one to try to solve something that way?

So it can be a loosing battle for many things, choose the best and
simplest solution, but always remember, Makefile order matters, which is
what I was wanting to correct here.

thanks,

greg k-h