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: <5240A0C2.4010502@wwwdotorg.org>
Date:	Mon, 23 Sep 2013 14:12:50 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Mark Brown <broonie@...nel.org>,
	Lars Poeschel <poeschel@...onage.de>,
	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>, joelf@...com
Subject: Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs

On 09/23/2013 01:53 PM, Linus Walleij wrote:
> On Wed, Sep 11, 2013 at 9:43 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> 
>> I believe this situation is exactly what cause the original patch to the
>> OMAP driver to be reverted; that patch should have touched the HW
>> directly to solve the problem when the IRQ was requested, rather than
>> calling into the GPIO subsystem (which also has the side-effect of
>> touching the HW in the same way as desired).
> 
> And that has the side-effect that this line, which is now set up
> in the HW as an input line, can be gpio_request()ed by some other
> code path and set up as output, screwing around with the very
> same registers.
> 
> I think the kernel should prevent such things.

It might be nice if it could do that.

However, that is 100% unrelated to the problem at hand.

A driver which only cares about an IRQ should be able to call just IRQ
APIs and have the HW work. Since not all IRQs are GPIOs, the thing that
causes the HW to work should not involve the GPIO subsystem in any way
at all.

So, the first issue - making a correctly configured system functionally
work without resorting to hacks such as requesting a GPIO to make an IRQ
work, is one thing. This issue should be solved purely inside the
specific HW driver.

Having the kernel detect when two different drivers both request the
same resource is entirely another thing. The solution to the first issue
must not rely on any solution to this second issue.

I'm also not convinced it's possible to solve this second issue given
the current kernel APIs, since there's not enough semantic information;
requests of GPIOs and IRQs aren't actually tied to a particular driver
at present (there's no "struct device *dev" parameter to request_irq or
gpio_request) and so the subsystems can't actually tell who is
requesting the GPIO/IRQ, and hence can't detect when the same driver, or
a different driver, is requesting the same core resource for different
purposes.

Equally, I am actually not 100% sure we want the core to prevent this.
Why shouldn't two different drivers request the same IRQ? Why shouldn't
at least one driver, perhaps more, request the pin as a GPIO (assuming
it will only read the GPIO value, not flip the pin to output). This
exact situation might happen on some Tegra boards where there's a GPIO
for VBUS_EN that affects 2 USB ports. It's supposed to be driven
open-collector. If an external entity forces it low, it means
over-current. Drivers for both ports might want to receive interrupts on
both edges, and even request the GPIO for input so they can both tell
which level the signal is at, in order to report OC/not-OC back up to
higher levels, as soon as any change occurs.
--
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/