linux-kernel - Re: [PATCH v2] 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]

Date:	Thu, 29 Aug 2013 21:00:32 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Tomasz Figa <tomasz.figa@...il.com>,
	Lars Poeschel <larsi@....tu-dresden.de>,
	Lars Poeschel <poeschel@...onage.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>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	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 v2] gpio: interrupt consistency check for OF GPIO IRQs

On Fri, Aug 23, 2013 at 9:52 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 08/23/2013 12:45 PM, Linus Walleij wrote:

>> This is a perfectly OK thing to do as long as it is done like
>> this:
>>
>> request_gpio(gpio);
>> gpio_direction_input(gpio);
>> request_irq(gpio_to_irq(gpio));
>
> But I'm not aware that there's a rule saying it's illegal to:
>
> request_irq(gpio_to_irq(gpio));
> request_gpio(gpio);
> gpio_direction_input(gpio);

No but I think there should be one ... maybe I'm an oddball
but it seems natural to request a GPIO before tying
IRQs to fire off it.

Besides, the bug that this is trying to solve is due to the
fact that the OMAP driver require exactly the former order
for the IRQs to work. I think if the sequence matters it is
likely to be the first form, but it's a rough guess.

>> Pass only the GPIO in the device tree and this works just fine.
>
> And I wouldn't be surprised if there were DTs that had separate GPIO and
> interrupt entries for the same pin.

That is the situation we want to catch.

Don't you agree that it has some bit of ambiguity around it, like
the tree makes an assumtion that whether you ask for the GPIO
line or IRQ first does not matter, and leave it up to the driver to
"do something" if the order suddenly turns out the other way around,
but is important to the hardware?

I think we can't get away from the ambition to define this
semantic for all DT systems.

> In fact, it's arguably technically
> more correct to do that than just list the GPIO, and then hope the OS
> will be able to convert it to the correct IRQ. Then, drivers wouldn't
> have any reason to believe they needed a specific IRQ-vs-GPIO request
> ordering.

If that is more technically correct (hm I wonder what measure is
used for "correctness" here) I think we are back at the GPIO input
hogs to achive what OMAP needs. Using such hogs they can
let the gpiochip node hog a few pins and set them as input rather
than each and every driver having to do so.

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/