linux-kernel - Re: [PATCH V3 1/3] ARM: imx: use device_initcall for imx_soc_device

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: <CAL_Jsq+2X-7=MKA4U8SDDwXWEvfTaiSK-tBUi8hMZKpSR+B-=w@mail.gmail.com>
Date:   Wed, 28 Oct 2020 08:28:05 -0500
From:   Rob Herring <robh@...nel.org>
To:     Peng Fan <peng.fan@....com>
Cc:     Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Abel Vesa <abel.vesa@....com>,
        Anson Huang <Anson.Huang@....com>,
        Andrey Smirnov <andrew.smirnov@...il.com>,
        Fabio Estevam <festevam@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        NXP Linux Team <linux-imx@....com>,
        Sascha Hauer <kernel@...gutronix.de>,
        André Draszik <git@...red.net>,
        Leonard Crestez <leonard.crestez@....com>,
        Enrico Weigelt <info@...ux.net>,
        Chris Healy <cphealy@...il.com>,
        Allison Randal <allison@...utok.net>
Subject: Re: [PATCH V3 1/3] ARM: imx: use device_initcall for imx_soc_device_init

On Wed, May 20, 2020 at 1:01 AM <peng.fan@....com> wrote:
>
> From: Peng Fan <peng.fan@....com>
>
> This is preparation to move imx_soc_device_init to drivers/soc/imx/
>
> There is no reason to must put dt devices under /sys/devices/soc0,
> they could also be under /sys/devices/platform, so we could
> pass NULL as parent when calling of_platform_default_populate.
>
> Following soc-imx8.c soc-imx-scu.c using device_initcall, need
> to change return type to int type for imx_soc_device_init.
>
> Signed-off-by: Peng Fan <peng.fan@....com>
> ---

> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 284bce1112d2..85c084a716ab 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -245,21 +245,15 @@ static void __init imx6q_axi_init(void)
>
>  static void __init imx6q_init_machine(void)
>  {
> -       struct device *parent;
> -
>         if (cpu_is_imx6q() && imx_get_soc_revision() == IMX_CHIP_REVISION_2_0)
>                 imx_print_silicon_rev("i.MX6QP", IMX_CHIP_REVISION_1_0);
>         else
>                 imx_print_silicon_rev(cpu_is_imx6dl() ? "i.MX6DL" : "i.MX6Q",
>                                 imx_get_soc_revision());
>
> -       parent = imx_soc_device_init();
> -       if (parent == NULL)
> -               pr_warn("failed to initialize soc device\n");
> -
>         imx6q_enet_phy_init();
>
> -       of_platform_default_populate(NULL, NULL, parent);
> +       of_platform_default_populate(NULL, NULL, NULL);

I know this is already applied, but really we want to get rid of
of_platform_default_populate calls and let the core code call it. i.MX
is one of the last remaining platforms to fix. This one remained
mainly because of 'parent'. Looks like there's some initcall ordering
issues to fix though. Maybe moving things to init_late works? If not,
moving the setup to drivers would be better if there's any ordering
issues as with deferred probe, initcalls alone don't guarantee the
order.

Rob