Hi Mark, On 6/30/2020 2:29 PM, Mark Tomlinson wrote: > The GPIO specified in the DTS file references the pinctrl, which is > specified after the GPIO. If the GPIO is initialised before pinctrl, May I know which GPIO driver you are referring to on NSP? Both the iProc GPIO driver and the NSP GPIO driver are initialized at the level of 'arch_initcall_sync', which is supposed to be after 'arch_initcall' used here in the pinmux driver > an error message for the -EPROBE_DEFER ends up in the kernel log. Even > though the probe will succeed when the driver is re-initialised, the > error can be scary to end users. To fix this, change the time the Scary to end users? I don't know about that. -EPROBE_DEFER was introduced exactly for this purpose. Perhaps users need to learn what -EPROBE_DEFER errno means? > pinctrl is probed, so that it is always before the GPIO driver. > > Signed-off-by: Mark Tomlinson <mark.tomlinson@xxxxxxxxxxxxxxxxxxx> > --- > drivers/pinctrl/bcm/pinctrl-nsp-mux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pinctrl/bcm/pinctrl-nsp-mux.c b/drivers/pinctrl/bcm/pinctrl-nsp-mux.c > index f1d60a708815..7586949f83ec 100644 > --- a/drivers/pinctrl/bcm/pinctrl-nsp-mux.c > +++ b/drivers/pinctrl/bcm/pinctrl-nsp-mux.c > @@ -639,4 +639,4 @@ static int __init nsp_pinmux_init(void) > { > return platform_driver_register(&nsp_pinmux_driver); > } > -arch_initcall(nsp_pinmux_init); > +postcore_initcall(nsp_pinmux_init); >