On Fri, Feb 20, 2026 at 08:55:52AM -0500, Joel Fernandes wrote: > > On Feb 20, 2026, at 5:17 AM, Danilo Krummrich <[email protected]> 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
