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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52154BF9.1060704@wwwdotorg.org>
Date:	Wed, 21 Aug 2013 17:23:37 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Stephen Warren <swarren@...dia.com>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Lars Poeschel <poeschel@...onage.de>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Subject: Re: [PATCH v2] pinctrl: queue GPIO operations instead of defering

On 08/21/2013 05:07 PM, Linus Walleij wrote:
> On Mon, Aug 19, 2013 at 9:15 PM, Stephen Warren <swarren@...dotorg.org> wrote:
>> On 08/17/2013 08:56 AM, Linus Walleij wrote:
> 
>>> and the pin controller need the GPIO driver to be ready.
>>
>> Why does that happen?
> 
> The pin controller call back into the GPIO-side controller
> functions by utilizing the GPIO ranges.
> (Maybe the code is silly, I dunno, check drivers/pinctrl/pinctrl-nomadik.c)
> 
>>> This also happens if
>>> pin controllers and GPIO controllers compiled as modules
>>> are inserted in a certain order.
>>
>> Shouldn't deferred probe resolve that just fine, assuming there are no
>> circular dependencies?
> 
> The above leads to circular dependencies so that is what I'm
> trying to fix with this.

But the circular dependencies are imposed by a specific driver, not by
the GPIO and pinctrl subsystems.

gpiolib operations call into pinctrl to acquire pin ownership. Hence, no
pinctrl operation (or implementation in a driver) can call into gpiolib,
or a GPIO driver.

Shouldn't this simply be fixed inside whichever driver is performing
circular operations, rather than leaving the driver performing circular
operations, and attemping to make the subsystems support something that
can't be supported?

>>> On the Nomadik we get this situation with the pinctrl
>>> driver when moving to requesting GPIOs off the gpiochip
>>> right after it has been added,
>>
>> So, the pinctrl driver calls gpio_request()? Surely the solution is
>> simply not to do that?
> 
> This is what the other patch we're discussing is doing.
> The one that harvests and requests interrupt GPIO's when
> a gpiochip is added...

It would have been good to mention the two patches were related, or did
I just miss that?

So that's another reason for me to object to that other patch. If that
whole process was triggered inside the IRQ controller implementation,
which is logically part of the GPIO controller implementation for the
same HW, the call direction would also be GPIO -> pinctrl or IRQ -> GPIO
-> pinctrl, and hence have no circular issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/