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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 24 Sep 2013 10:26:10 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>,
	Alexandre Courbot <acourbot@...dia.com>
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 Mon, Sep 23, 2013 at 10:12 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 09/23/2013 01:53 PM, Linus Walleij wrote:

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

I don't think it is unrelated when the old OMAP boardfile-based
code definately prevents such uses by its strict usage
of gpio_request() for all IRQ-bound GPIOs.

I think not preventing it for the DT boot path is setting lower
standards for DT code than for boardfile code which is not
what we should be doing.

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

Yes I have bought into that concept now.

> 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 understand this stance from a DT point of view - which is about
resource passing and its syntax and semantics.

>From a GPIO subsystem point of view, in keeping resources under
kernel control, I naturally do not agree.

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

Solving the issue that e.g. two different drivers competing about the
same resource (as in one driver requesting an IRQ and another one
requesting a GPIO) is not what I'm after here.

I'm more after the GPIO subsystem having knowledge of a certain
GPIO line being requested for IRQ, and denying that line to be set
as input.

Maybe this can actually be achieved quite easily with
an additional API? Like gpio_lock_as_irq(gpio) which flags this
in .flags of struct gpio_desc and prevent such things?

Alexandre what do you think about this idea?

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

But I have already stated that this is OK?

Are we talking past each other now?

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

You are describing a very good reason for the core to be
doing exactly what I described I think?

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/