[PATCH 0/3] gpio/pinctrl: imx: let IOMUX controller know about on-SoC GPIOs

[Vladimir Zapolskiy]

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 at kernel.org>
>

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