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

[Koen Koning <koen.koning@linux.intel.com>]

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 <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.
> 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.