Hi Rob,

> 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@nxp.com> wrote:
> >
> > From: Peng Fan <peng.fan@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@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.

Understand.

 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.

I did one patch before, but breaks i.MX6Q pm code,
https://patchwork.ozlabs.org/project/linux-imx/patch/
20190313091757.16410-1-peng.fan@nxp.com/

Indeed there are some order issue, I will try again to clean up the stuff.

Thanks,
Peng.

> 
> Rob