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,
--
Joel Fernandes
