On Mon, Sep 05, 2016 at 02:49:16PM +0300, Vladimir Zapolskiy wrote:

quoted

If I understand it correctly, with the change, most of GPIO client
device drivers use the same init level as GPIO driver.  So we are not
sure if GPIO driver is ready when client drivers try to request GPIO.

please give it a test run (with and without DTS gpio-ranges changes,
or just 2/3 from the series), I've tested on iMX6Q SabreLite, SabreAuto,
SabreSD and I don't see any regressions or noticeable increase of
-EPROBE_DEFER hits due to not ready GPIOs.

quoted

most of GPIO client device drivers use the same init level as GPIO driver.

IMHO that will be the case, if the change 2/3 from the series is applied.

Statisticaly most of GPIO consumers should settle on device_initcall or
module_init level, the latter one is translated to device_initcall if
a driver is built-in, so the proposed downgrading of GPIO controller
driver init call level looks to be appropriate.

However pinctrl/pinmux driver should definitely have higher init level
priority in comparison to GPIO controller driver, every GPIO consumer
is a pinctrl/pinmux consumer as well, most of iMX pinctrl/pinmux drivers
are initialized at arch_initcall level, so there is a plenty of options
to satisfy (GPIO driver initcall) < (pinmux/pinctrl driver initcall)
equation:
* change pinmux/pinctrl driver initcall level to postcore_initcall
  and GPIO driver initcall level to arch_initcall or lower one,
* keep pinmux/pinctrl driver at arch_initcall level, set GPIO driver
  initcall level to any lower than arch_initcall (e.g. device_initcall)
* keep everything as is, drop 2/3 and rely on -EPROBE_DEFER from
  GPIO driver probe due to not yet initialized pinctrl driver.

quoted

It shouldn't be a problem if every client driver handle the failure
with deferred probing, but I'm not sure that's the case now.

From what I see it is the case for the most critical drivers, for the
rest I believe it is a bug, which can be revealed by shifting GPIO
driver initcall level and fixed, see also

https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003419.html

Okay, fair enough.

For the series,

Acked-by: Shawn Guo <shawnguo@kernel.org>