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] [day] [month] [year] [list]

Date:	Thu, 22 Aug 2013 01:44:42 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.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 Thu, Aug 22, 2013 at 1:23 AM, Stephen Warren <swarren@...dotorg.org> wrote:

> 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?

It was part of that series, but I thought about it and saw that
it'd be nice if the GPIO probing would not have to defer
due to the pin controller not being up yet anyway.

I'll just reword the subject like that... like some nice
optimization.

Actually I think we should be able to register GPIO ranges
before the backing pin controller is up as well for the
same reason, letting such things queue up will make
the boot more optimal in some cases and get people
away from playing around with initcall levels.

>> 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?

In the first posting it was. I need to refine the motivation
per above instead.

> 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.

Hm not quite following, but it was not triggered from the IRQ
controller. It was triggered from the gpiolib-of.c trying to
do gpio_request() and gpio_set_input() right after registering
a GPIO controller. (Which should be possible, it's a bug in
its own right that this is not possible on the Nomadik driver...)

Yours,
Linus Walleij
--
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/