On Mon, Aug 7, 2017 at 1:01 PM, Michal Simek <michal.simek@xxxxxxxxxx> wrote: > From: Nava kishore Manne <nava.manne@xxxxxxxxxx> > > In general situation on-SoC GPIO controller drivers should be probed > after pinctrl/pinmux controller driver, because on-SoC GPIOs utilize a > pin/pad as a resource provided and controlled by pinctrl subsystem. > > GPIO must come after pinctrl as gpios may need to mux pins....etc > > Looking at Xilinx SoC series pinctrl drivers, zynq*_pinctrl_init() > functions are called at arch_initcall init levels, > so the change of initcall level for gpio-zynq driver from > postcore_initcall to subsys_initcall level is sufficient. Also note > that the most of GPIO controller drivers settled at subsys_initcall > level. > > If pinctrl subsystem manages pads with GPIO functions, the change is > needed to avoid unwanted driver probe deferrals during kernel boot. > > Signed-off-by: Nava kishore Manne <navam@xxxxxxxxxx> > Signed-off-by: Michal Simek <michal.simek@xxxxxxxxxx> Can't you just move it all the way to device_initcall and simply use the standard module init macros? builtin_platform_driver(), module_platform_driver()? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html