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: <CACRpkdacx-e01i_h4cj1qMX2zNOiiDshbTV__wi_LfQrLkrL6g@mail.gmail.com>
Date:	Mon, 23 Sep 2013 21:53:07 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.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 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.

But I think you're making it sound like the kernel should not prevent
such things, but instead give the drivers enough rope to shoot itself
in the foot if it so desires.

But a third solution is possible: the driver keep track of whether
a line is already requested as IRQ and if that happens, will not
allow gpio_set_direction_output() and other incompatible uses,
but still allow gpio_set_direction_input() and gpio_get_value(),
that would be OK.

In the GPIO descriptor we can flag this, so it would be preferable
to have that tracking in the gpiolib core rather than the driver
though.

> As we discussed on IRC (so mainly for the record in the mailing list
> archive), I believe that if a driver wants to use a pin as an interrupt
> and only an interrupt, even if the pin has the capability in HW to be a
> GPIO (or absolutely anything else at all), then the only call in the
> entire kernel (board code, DT core code, IRQ core, driver, ...) should
> be a single request_irq(), and the IRQ chip driver needs to program the
> HW appropriately to make that work.

I agree with this, but also think that the kernel should prevent the
same resource for being used in an incompatible way.

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/