[PATCH V3 1/3] ARM: imx: use device_initcall for imx_soc_device_init
Peng Fan
peng.fan at nxp.com
Wed Oct 28 09:57:55 EDT 2020
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 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.
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 at nxp.com/
Indeed there are some order issue, I will try again to clean up the stuff.
Thanks,
Peng.
>
> Rob
More information about the linux-arm-kernel
mailing list