Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <7e52bb17-cbd4-eec2-092a-65c4a01d41ba@rasmusvillemoes.dk>
Date:   Mon, 24 Oct 2022 16:31:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH] clk: imx8mp: register driver at arch_initcall time
Content-Language: en-US
To:     Ahmad Fatoum <a.fatoum@pengutronix.de>,
        Abel Vesa <abelvesa@kernel.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Stephen Boyd <sboyd@kernel.org>,
        Shawn Guo <shawnguo@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Fabio Estevam <festevam@gmail.com>,
        NXP Linux Team <linux-imx@nxp.com>
Cc:     linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
References: <20220928124108.500369-1-linux@rasmusvillemoes.dk>
 <814496ae-4007-9a4e-0466-a0386aec6316@rasmusvillemoes.dk>
 <ed50cdff-8fd2-6714-9b0b-1ce47a5c9d37@pengutronix.de>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
In-Reply-To: <ed50cdff-8fd2-6714-9b0b-1ce47a5c9d37@pengutronix.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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