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

On Fri, Aug 05, 2011 at 10:40:17AM +0100, Russell King - ARM Linux wrote:
> 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.

Yes, and there's a pile without these defined/
 
> 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.

What about the case where we need to turn GPIO numbers into interrupts
to pass to other drivers? In the case where we have a gpio chip that is
providing interrupt services to other drivers (such as serial chip).

Having looked at a couple of IIO drivers, it seems that the need to use
irq_to_gpio() seems to be to check if the device needs to be service. It
would be useful to see if this is due to a problem with the threadder IRQ
handler (and if so, may need fixing for the general case).

-- 
Ben Dooks, ben@...ff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

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