[PATCH] irqchip: let the probe of APLIC be earlier than IMSIC

[Thomas Gleixner]

On Mon, Aug 05 2024 at 10:43, Vincent Chen wrote:
> On Fri, Aug 2, 2024 at 7:03 PM Anup Patel <anup at brainfault.org> wrote:
>> Secondly, changing compilation order in Makefile to influence
>> the probe order will not help in any way.
>>
> I was confused here. If possible, hope you can help me clarify it.
> The following is the backtrace of really_porbe() dumped by GDB.
> #0  0xffffffff8092318a in really_probe ()
> #1  0xffffffff80923516 in __driver_probe_device.part.0 ()
> #2  0xffffffff8057c856 in driver_probe_device ()
> #3  0xffffffff8057c9ba in __driver_attach ()
> #4  0xffffffff8057aaa4 in bus_for_each_dev ()
> #5  0xffffffff8057c3ea in driver_attach ()
> #6  0xffffffff8057bc4a in bus_add_driver ()
> #7  0xffffffff8057d75a in driver_register ()
> #8  0xffffffff8057e83c in __platform_driver_register ()
> #9  0xffffffff80a2455e in imsic_platform_driver_init ()
> #10 0xffffffff8000212c in do_one_initcall ()
> #11 0xffffffff80a01188 in kernel_init_freeable ()
> #12 0xffffffff80928d80 in kernel_init ()
>
> According to this result, the source to call really_probe is
> do_one_initcall(), regardless of whether it is APLIC or IMSIC. The
> do_one_initcall() function follows the placed order of the
> initialization functions in the __initcall6 section to invoke them.
> The compile order determines the order of the __initcall6 section.
> Therefore, I try to adjust the compile order to influence the probe
> order between IMSIC and APLIC. Do I misunderstand something?

There is no guarantee that this order is retained. The linker can freely
reorg the section. That's why we have deferred probing. It's neither a
bug nor a problem, so what are you trying to solve?

Thanks,

        tglx