[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1dc8f14-187d-a804-45bb-d1fa25ff7b01@broadcom.com>
Date: Tue, 30 Jun 2020 15:08:05 -0700
From: Ray Jui <ray.jui@...adcom.com>
To: Mark Tomlinson <mark.tomlinson@...iedtelesis.co.nz>,
rjui@...adcom.com, sbranden@...adcom.com,
bcm-kernel-feedback-list@...adcom.com, linus.walleij@...aro.org,
linux-gpio@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: initialise nsp-mux earlier.
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@...iedtelesis.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);
>
Powered by blists - more mailing lists