Hi Shawn,
On 09/08/2016 04:41 AM, Shawn Guo wrote:
On Mon, Sep 05, 2016 at 02:49:16PM +0300, Vladimir Zapolskiy wrote:
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.
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.
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@xxxxxxxxxx>
thank you for review/ack, just in parallel I've sent v2 with a shift
to subsys_initcall, which, I agree, might be more preferrable.
If you more like v2, please ack that series.
Thank you in advance.
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
