linux-kernel - Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs

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: <52279524.8090006@wwwdotorg.org>
Date:	Wed, 04 Sep 2013 14:16:36 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Lars Poeschel <poeschel@...onage.de>
CC:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	Lars Poeschel <larsi@....tu-dresden.de>,
	Grant Likely <grant.likely@...aro.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Kumar Gala <galak@...eaurora.org>,
	Pawel Moll <pawel.moll@....com>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Enric Balletbo i Serra <eballetbo@...il.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	Kevin Hilman <khilman@...aro.org>,
	Balaji T K <balajitk@...com>,
	Tony Lindgren <tony@...mide.com>,
	Jon Hunter <jgchunter@...il.com>
Subject: Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs

On 09/04/2013 03:05 AM, Lars Poeschel wrote:
> On Wednesday 04 September 2013 11:27:12, Stephen Warren wrote:
>> On 09/02/2013 03:25 AM, Lars Poeschel wrote:
>>> Some leagcy drivers currently do this:
>>>
>>> request_gpio(gpio);
>>> gpio_direction_input(gpio);
>>> request_irq(gpio_to_irq(gpio));
>>>
>>> In that case request_irq should not fail because the driver is already the
>>> correct owner of this gpio. But if some other entity owns this gpio it
>>> should fail.
>>
>> Yes.
>>
>>> Also if I understand you correct the other way round should also possible:
>>>
>>> request_irq(gpio_to_irq(gpio));
>>> request_gpio(gpio);
>>> gpio_direction_input(gpio);
>>>
>>> request_irq() also requests the gpio then but the following request_gpio()
>>> should also not fail.
>>
>> I don't believe that code sequence is currently banned. If we want to
>> ban it, we should document that. Until this is documented as being
>> banned, I think we must fully support that code sequence.
>>
>>> To have it work that way we have to track the owners of all requested
>>> gpios
>>> somewhere. Or am I wrong here?
>>> Where and how to record these owners? Can gpio system achieve this? gpios
>>> are requested without an owning device.
>>
>> Yes. But, I believe we need to fully track every GPIO/IRQ owner already
>> right now; if a driver (not the GPIO/IRQ chip driver, but a driver that
>> uses the GPIOs/IRQs) calls gpio_request()/request_irq(), and this patch
>> has already requested them, then we already need to fully track GPIO/IRQ
>> ownership to make sure that the driver's own requests aren't failed
>> because the DT/GPIO core has already requested them on its behalf.
> 
> The driver that tries to use the GPIO requested by this patch before HAS to 
> fail. This is exactly the intention of this patch. We don't want the GPIO to 
> be requested any more, if it is used as an interrupt pin.

That will break existing drivers. There are drivers that request the
same GPIO and IRQ. IIRC, the SDHCI CD (Card Detect) GPIO is requested
that way.

> To be able to implement the way you proposed some mails before, I have to be 
> able to do some checks that to my opinion (and if I understand Linus 
> correctly) aren't possible at the moment.

True.

> So I asked, where and how to record 
> these owners of the GPIOs? And can the GPIO system achieve this and how? Can 
> you please shed some light on this! Thanks!

Alex Courbot's (proposed) new gpiod API has a "dev" parameter to
gpiod_request() which could be used for this purpose. Something similar
could be done for interrupts.
--
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/