diff options
author | Ahmad Fatoum <a.fatoum@pengutronix.de> | 2022-10-05 21:41:08 +0200 |
---|---|---|
committer | Sascha Hauer <s.hauer@pengutronix.de> | 2022-10-06 10:42:34 +0200 |
commit | ac33f77ac47ffb2c1de4029ae1083d6f4e421e32 (patch) | |
tree | ec861acedf3b64d8cfe4f87adad849c8237c4a37 /dts/src/arm64/broadcom/stingray | |
parent | 8a805a26bc724f4193c79037c1d0c1d2c87dd06e (diff) | |
download | barebox-ac33f77ac47ffb2c1de4029ae1083d6f4e421e32.tar.gz barebox-ac33f77ac47ffb2c1de4029ae1083d6f4e421e32.tar.xz |
clks: imx7: fix initial clock setup with deep probe enabled
We register the i.MX7 clock controller driver at core_initcall level and
then do some initial clock setup/reparenting at postcore_initcall level.
This doesn't work as expected when deep probe is enabled, because while
the driver is registered at core_initcall level, it's only probed
later on, currently at postcore_initcall level because it's a dependency
of the timer for which of_ensure_device_probed is called.
As the initial clock setup is also at postcore_initcall level, it's no
longer guaranteed that the code executes in the same order. Fix this by
directly doing the setup at the end of the probe function for the deep
probe case. In non-deep-probe systems, we maintain the existing initcall
ordering to avoid regressions.
Co-developed-by: Johannes Zink <j.zink@pengutronix.de>
Signed-off-by: Johannes Zink <j.zink@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Link: https://lore.barebox.org/20221005194108.3380781-1-a.fatoum@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Diffstat (limited to 'dts/src/arm64/broadcom/stingray')
0 files changed, 0 insertions, 0 deletions