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] [day] [month] [year] [list]

Message-Id: <20221123014233.D88DCC433D6@smtp.kernel.org>
Date:   Tue, 22 Nov 2022 17:42:31 -0800
From:   Stephen Boyd <sboyd@...nel.org>
To:     Abel Vesa <abel.vesa@...aro.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Abel Vesa <abelvesa@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        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>,
        linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH] clk: imx8mp: register driver at arch_initcall time

Quoting Rasmus Villemoes (2022-11-21 23:49:50)
> 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,

There is a maintenance burden. Moving the initcall around is papering
over the problem by not clearly describing the requirement to probe the
watchdog driver as soon as possible. I don't expect to remember years
from now that the watchdog driver needed this driver and the pinctrl
driver to avoid probe defer, otherwise the watchdog will bite because it
probes too late.

The problem is not being solved directly. That's why we're concerned.
Maybe if the problem statement was "don't allow probe defer", and that
was worked into the driver core so drivers can be marked as "panic when
this driver probe defers" then it would be more obvious what sort of
behavior we don't want.

Or to go further, maybe this board compatible needs to probe a board
driver that only adds the clk, pinctrl, and watchdog devices as a first
pass with a comment that these devices need to be probed as soon as
possible to avoid watchdog bites on that board. Then once those devices
are probed it can add the rest of the devices.

> 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.
> 

The usage of arch_initcall() and core_initcall() should be fixed.