On Mon, Mar 18, 2019 at 02:31:34AM +0000, Peng Fan wrote: > > > > -----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.
Ah, okay. Thanks for the careful review and the check, Aisheng, Peng. Shawn
