linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e52bb17-cbd4-eec2-092a-65c4a01d41ba@rasmusvillemoes.dk>
Date:   Mon, 24 Oct 2022 16:31:07 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Ahmad Fatoum <a.fatoum@...gutronix.de>,
        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
Subject: Re: [PATCH] clk: imx8mp: register driver at arch_initcall time

On 24/10/2022 16.00, Ahmad Fatoum wrote:
> Hello Rasmus,
> 
> On 24.10.22 15:48, Rasmus Villemoes wrote:
>> On 28/09/2022 14.41, Rasmus Villemoes wrote:
>>> 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.
>>
>> ping
> 
> Module build is unaffected, because arch_initcall expands to module_init
> if it's built as a module, right?

Yes.

 Noting that in the commit message would
> be good I think.
> 
> Also, did you try booting with fw_devlink=on? This should have resolved
> your issue too. Not sure what other issues it may cause on i.MX8MP.

AFAICT, that's the default behaviour:

drivers/base/core.c:static u32 fw_devlink_flags = FW_DEVLINK_FLAGS_ON;
drivers/base/core.c-static int __init fw_devlink_setup(char *arg)
drivers/base/core.c-{
drivers/base/core.c-    if (!arg)
drivers/base/core.c-            return -EINVAL;
drivers/base/core.c-
drivers/base/core.c-    if (strcmp(arg, "off") == 0) {
drivers/base/core.c:            fw_devlink_flags = 0;
drivers/base/core.c-    } else if (strcmp(arg, "permissive") == 0) {
drivers/base/core.c:            fw_devlink_flags =
FW_DEVLINK_FLAGS_PERMISSIVE;
drivers/base/core.c-    } else if (strcmp(arg, "on") == 0) {
drivers/base/core.c:            fw_devlink_flags = FW_DEVLINK_FLAGS_ON;
drivers/base/core.c-    } else if (strcmp(arg, "rpm") == 0) {
drivers/base/core.c:            fw_devlink_flags = FW_DEVLINK_FLAGS_RPM;
drivers/base/core.c-    }
drivers/base/core.c-    return 0;
drivers/base/core.c-}
drivers/base/core.c-early_param("fw_devlink", fw_devlink_setup);

But I don't think the problem is that the driver core has inferred the
dependency chain upfront from parsing DT; the problem is simply that we
end up probing the clock controller, and hence all dependencies too late.

Rasmus