[PATCH] clk: clk-imx8mm: Initialize clocks in arch_initcall

[Paul Geurts]

> On 26-04-08 12:13:13, Paul Geurts wrote:
>> The i.MX8MM clock driver is implemented as module_platform_driver();,
>> which makes it initialize in device_initcall(). This means that all
>> drivers referencing the clock driver nodes in the device tree are
>> deferred by fw_devlink, which are most of the i.MX8M platform drivers.
>>
>> Explicitly initialize the clock driver in arch_initcall(), to make sure
>> the clock driver is ready when the rest of the drivers are probed.
>>
>> Fixes: af7e7ee0e428 ("clk: imx8mm: Switch to platform driver")
>> Signed-off-by: Paul Geurts <paul.geurts at prodrive-technologies.com>
> 
> Nack.
> 
> Nothing wrong with probe deferring. It is there to ensure the order
> the drivers probe in is correct.
> 
> Plus, moving it to arch_initcall won't solve anything.
I disagree, as it solves a _lot_ on my setup. But I think the next section
explains it better.

> 
> fw_devlink will not stop the driver from probing if there is no provider
> that this driver is waiting for. And if there is a provider that is
> needed by this clock controller, moving it to arch_initcall won't
> magically skip waiting for the provider anyway.
I think you have the issue backwards. There is no provider that is needed
by the clock controller. The clock controller is needed by everything else.
So the clock controller is not deferred. All other things are deferred because
of the clock controller.

I understand that probe deferring is not there for nothing. But I would also
argue that the initcall levels are also not there for nothing. IMO a chip
clock controller is an architecture driver, and belongs in arch_. Whether this
is the correct way to do it, or whether this driver should be able to be
compiled as a module is a separate discussion. 

br, Paul