Re: [PATCH] pinctrl: initialise nsp-mux earlier.

[Ray Jui <ray.jui@broadcom.com>]

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@alliedtelesis.co.nz>
> ---
>  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);
>