> -----Original Message----- > From: Aisheng Dong > Sent: 2019年3月15日 21:39 > To: Peng Fan <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; > dl-linux-imx <[email protected]>; Anson Huang <[email protected]>; > [email protected]; [email protected]; > [email protected] > Cc: [email protected] > Subject: RE: [PATCH 1/2] ARM: imx: drop uneccessary > of_platform_default_populate > > [...] > > > > Originally devices are registered in arch_initcall. Now it will be a > > > bit later in arch_initcall_sync and this may cause a bit risk if the > > > code under the default_populate want to access the device service > > > provided > > by early probe. > > > > > > Probably it's more safe to leave as it is unless you can double > > > confirm there're no such code depends on accessing early probed > > > devices as follows before we can make the change. > > > > This has been boot tested on 6Q-SDB/6UL-EVK/6SL-EVK board. > > For i.MX, I only see pinctrl driver use arch_initcall from the link, > > https://elixir.bootlin.com/linux/latest/ident/arch_initcall > > > > From my boot test, the pinctrl driver probe will be delayed a bit, but > > I do not see issues. > > > > From what I saw, imx6q_1588_init() and imx6q_axi_init() will use syscon which > is registered with postcore_initcall. Without having syscon devices populated, > I wonder those calls may fall. > Can you double check it?
I do not see failure in imx6q_1588_init by adding a return value check of regmap_update_bits, But the imx6q_pm_init will find ocram device for suspend usage, postpone the device population will make imx6q_pm_init fail, so drop this patch and leave the code as it is. Thanks, Peng. > > Regards > Dong Aisheng
