[PATCH V3 1/3] ARM: imx: use device_initcall for imx_soc_device_init

Rob Herring robh at kernel.org
Wed Oct 28 09:28:05 EDT 2020


On Wed, May 20, 2020 at 1:01 AM <peng.fan at nxp.com> wrote:
>
> From: Peng Fan <peng.fan at nxp.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 at nxp.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



More information about the linux-arm-kernel mailing list