linux-kernel - [PATCH] clk: imx8mp: register driver at arch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20220928124108.500369-1-linux@rasmusvillemoes.dk>
Date:   Wed, 28 Sep 2022 14:41:08 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Abel Vesa <abelvesa@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>
Cc:     linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: [PATCH] clk: imx8mp: register driver at arch_initcall time

We have an imx8mp-based board with an external gpio-triggered
watchdog. Currently, we don't get to handle that in time before it
resets the board.

The probe of the watchdog device gets deferred because the SOC's GPIO
controller is not yet ready, and the probe of that in turn gets deferred
because its clock provider (namely, this driver) is not yet
ready. Altogether, the watchdog does not get handled until the late
initcall deferred_probe_initcall has made sure all leftover devices
have been probed, and that's way too late.

Aside from being necessary for our board, this also reduces total boot
time because fewer device probes get deferred.

Signed-off-by: Rasmus Villemoes <linux@...musvillemoes.dk>
---
It would probably be reasonable to do the same to the other imx8m* clk
drivers, but I don't have any such hardware to test on.

 drivers/clk/imx/clk-imx8mp.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index e89db568f5a8..9ddd39a664cc 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -734,7 +734,19 @@ static struct platform_driver imx8mp_clk_driver = {
 		.of_match_table = imx8mp_clk_of_match,
 	},
 };
-module_platform_driver(imx8mp_clk_driver);
+
+static int __init imx8mp_clk_init(void)
+{
+	return platform_driver_register(&imx8mp_clk_driver);
+}
+arch_initcall(imx8mp_clk_init);
+
+static void __exit imx8mp_clk_exit(void)
+{
+	platform_driver_unregister(&imx8mp_clk_driver);
+}
+module_exit(imx8mp_clk_exit);
+
 module_param(mcore_booted, bool, S_IRUGO);
 MODULE_PARM_DESC(mcore_booted, "See Cortex-M core is booted or not");
 
-- 
2.37.2