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: <97c249fd-21c5-acc2-6195-bf0aed5bee8f@rasmusvillemoes.dk>
Date:   Tue, 22 Nov 2022 08:49:50 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH] clk: imx8mp: register driver at arch_initcall time
Content-Language: en-US, da
To:     Abel Vesa <abel.vesa@linaro.org>
Cc:     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>,
        linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org
References: <20220928124108.500369-1-linux@rasmusvillemoes.dk>
 <Y3ucncQOBNHpZaxn@linaro.org>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
In-Reply-To: <Y3ucncQOBNHpZaxn@linaro.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 21/11/2022 16.43, Abel Vesa wrote:
> On 22-09-28 14:41:08, 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.
>>
> 
> I'm gonna be honest here. I can't say I'm happy with this.
> I would suggest finding a solution to disable the external watchdog
> before booting the kernel, up until the driver probes, would be preferable
> to me.

That's not an option (it would violate the very purpose of having an
external always-running watchdog), and also simply not possible on the
given hardware.

I don't understand why this simple patch can't just be applied. It hurts
nothing, it makes all imx8mp boards boot very slightly faster, there's
no maintenance burden associated with the boilerplate code, it allows
hardware that already exists to actually work with a mainline kernel
out-of-the-box. And in an alternate universe where the init function had
been arch_initcall in the initial commit (such as those in
drivers/clk/mediatek/), nobody would have asked any questions.

Rasmus