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

[Mark Tomlinson <Mark.Tomlinson@alliedtelesis.co.nz>]

On Tue, 2020-06-30 at 15:08 -0700, Ray Jui wrote:
> 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

Sorry, it looks like I made a mistake in my testing (or I was lucky),
and this patch doesn't fix the issue. What is happening is:
1) nsp-pinmux driver is registered (arch_initcall).
2) nsp-gpio-a driver is registered (arch_initcall_sync).
3) of_platform_default_populate_init() is called (also at level
arch_initcall_sync), which scans the device tree, adds the nsp-gpio-a
device, runs its probe, and this returns -EPROBE_DEFER with the error
message.
4) Only now nsp-pinmux device is probed.

Changing the 'arch_initcall_sync' to 'device_initcall' in nsp-gpio-a
ensures that the pinmux is probed first since
of_platform_default_populate_init() will be called between the two
register calls, and the error goes away. Is this change acceptable as a
solution?

> > 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?

The actual error message in syslog is:

kern.err kernel: gpiochip_add_data_with_key: GPIOs 480..511
(18000020.gpio) failed to register, -517

So an end user sees "err" and "failed", and doesn't know what "-517"
means.