On Mon Feb 23, 2026 at 01:49 +0100, Joel Fernandes wrote:
On 2/21/2026 12:44 AM, Greg KH wrote:
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.
Fair enough, the solution you are suggesting also sounds good to me.
Thanks that makes sense, then let's just stick to addressing the current
regression with gpu/buddy in the drm-tip tree.
Joel, could you grab the v1 of this patchset (or the v2 with with
subsys_initcall, either works) and try to get it applied to drm-tip?
Since this is my first time submitting patches, I'm not really sure how
to proceed from here, and it will probably be faster if you have a look.
