Re: [PATCH v2] pinctrl: queue GPIO operations instead of defering

[Linus Walleij]

On Wed, Aug 21, 2013 at 7:45 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 08/19/2013 01:21 PM, Stephen Warren wrote:
>> On 08/17/2013 08:56 AM, Linus Walleij wrote:
>>> We currently defer probing of the caller if a pinctrl GPIO
>>> request or direction setting comes in before the range mapping
>>> a certain GPIO to a certain pin controller is available.
>>>
>>> This can end up with a circular dependency: the GPIO driver
>>> needs the pin controller to be ready and the pin controller
>>> need the GPIO driver to be ready. This also happens if
>>> pin controllers and GPIO controllers compiled as modules
>>> are inserted in a certain order.
>>>
>>> To break this circular dependence, queue any GPIO
>>> operations coming to the framework until the range is ready,
>>> instead of deferring the probe of the caller.
>>
>> I just noticed that next-20130819 is failing on the Tegra114 Dalmore
>> board because of this patch. The kernel log is below. Reverting this
>> patch solves the problem
>
> Linus, any thoughts here?

None whatsoever, but logically it should be that your pinctrl+GPIO
driver pair depends on the GPIO driver coming first and having it's probing
deferred.

I'll rip out that patch for the time being...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/