On Sun, Jul 28, 2013 at 12:58 PM, Alexander Holler <[email protected]> wrote: > Am 28.06.2013 17:27, schrieb Javier Martinez Canillas: > >> When a GPIO is defined as an interrupt line using Device >> Tree, a call to irq_create_of_mapping() is made that calls >> irq_create_mapping(). So, is not necessary to do the mapping >> for all OMAP GPIO lines and explicitly call irq_create_mapping() >> on the driver probe() when booting with Device Tree. >> >> Add a custom IRQ domain .map function handler that will be >> called by irq_create_mapping() to map the GPIO lines used as IRQ. >> This also allows to execute needed setup code such as configuring >> a GPIO as input and enabling the GPIO bank. > > > This patch basically broke every usage of > > irq = gpio_to_irq(gpio); > request[_threaded]_irq(irq, ...); > > because request[_threaded]_irq(irq, ...) now fails because of a missing > irq_domain (no mapping => no domain).
OK and I had ACKs from Santosh and even a Test-by tag from Enric on that thing. What shall we do with this mess now? I was told that these patches really needed to be applied because they were fixing a regression in v3.11, and now it seems they are causing another regression. What I need to know is what is worst: having these three patches there or reverting them? Or should I simply revert *all* the TI GPIO stuff merged for v3.11 now that is seems like this is a can of worms? :-/ Tony, Kevin, Santosh, someone? What will make all happy? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
