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: <20221027232914.2F51DC43470@smtp.kernel.org>
Date:   Thu, 27 Oct 2022 16:29:12 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Abel Vesa <abelvesa@...nel.org>,
        Fabio Estevam <festevam@...il.com>,
        Michael Turquette <mturquette@...libre.com>,
        NXP Linux Team <linux-imx@....com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: Re: [PATCH] clk: imx8mp: register driver at arch_initcall time

Quoting Rasmus Villemoes (2022-09-28 05:41:08)
> 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.

How much time does your bootloader give you to pet the watchdog? Why is
the timeout short enough to trigger? Or is deferring probe slowing down
boot so significantly that boot times are bad?

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

This is a game of whack-a-mole. If we decide to move device population
from DT (of_platform_default_populate_init) to device_initcall() level
we may run into a similar problem.

> 
> 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);

Furthermore, there isn't any comment about why this is arch_initcall
level. The next reader of this code can only assume why this was done or
go on a git archaeology dig to figure out that we're registering this
device early for some imx8mp-based board (is it upstream? What board is
it?). Please help people reading the code.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ