linux-kernel - Re: [RFC PATCH 0/3] If an IRQ is a GPIO, request and configure it

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:	Fri, 5 Aug 2011 10:40:17 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...com>, Chris Ball <cjb@...top.org>,
	ccross@...roid.com, olof@...om.net, alsa-devel@...a-project.org,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-tegra@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH 0/3] If an IRQ is a GPIO, request and configure it

On Thu, Aug 04, 2011 at 05:00:17PM -0600, Stephen Warren wrote:
> In http://www.spinics.net/lists/linux-tegra/msg01731.html, Mark Brown
> pointed out that it was a little silly forcing every board or driver
> to gpio_request() a GPIO that is later converted to an IRQ, and passed
> to request_irq. The first patch in this series instead makes the core
> IRQ code perform these calls when appropriate, to avoid duplicating it
> everywhere.

Trying to go from IRQ to GPIO is not a good idea - most of the
IRQ <-> GPIO macros we have today are just plain broken.  Many of them
just add or subtract a constant, which means non-GPIO IRQs have an
apparant GPIO number too.  Couple this with the fact that all positive
GPIO numbers are valid, and this is a recipe for wrong GPIOs getting
used and GPIOs being requested for non-GPIO IRQs.

I think this was also discussed in the past, and the conclusion was that
IRQs should be kept separate from GPIOs.  Maybe views have changed since
then...

However, if we do want to do this, then it would be much better to provide
a new API for requesting GPIO IRQs, eg:

gpio_request_irq()

which would wrap around request_threaded_irq(), takes a GPIO number,
does the GPIO->IRQ conversion internally, and whatever GPIO setup is
required.  Something like this:

int gpio_request_threaded_irq(int gpio, irq_handler_t handler,
	irq_handler_t thread_fn, unsigned long flags, const char *name,
	void *dev)
{
	int ret;

	if (!gpio_valid(gpio))
		return -EINVAL;

	ret = gpio_request_one(gpio, GPIOF_IN, name);
	if (ret)
		return ret;

	ret = request_threaded_irq(gpio_to_irq(gpio), handler, thread_fn,
				flags, name, dev);
	if (ret)
		gpio_free(gpio);

	return ret;
}

This then limits the exposure of the GPIO<->IRQ conversion macros to just
GPIOs, where the buggy nature of the existing conversions won't impact on
non-GPIO IRQs.
--
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/