On Fri, Oct 11, 2013 at 9:10 PM, Stephen Warren <[email protected]> wrote: > On 10/11/2013 02:39 AM, Linus Walleij wrote:
>> However that is not the whole story, is it? We have a gazillion >> drivers calling irq_create_mapping() in this function, so I would >> say that things are already a mess here. > > I expect things are a mess indeed:-) > > I believe that if a driver is only calling irq_create_mapping() inside > gpio_to_irq(), it's a bug. I think things can operate correctly in one > of two cases, at least with DT: > > 1) irq_create_mapping() is called from both gpio_to_irq() and the > of_xlate callback for IRQs. > > (I don't think this method would work in a board-file-based system where > of_xlate isn't called for IRQs...) > > or: > > 2) irq_create_mapping() is called for all IRQs when registering the IRQ > controller/domain. > > To me, (2) is much simpler, and avoids the issue (1) probably has with > only supporting direct IRQ usage (without something calling gpio_to_irq()). Hm. Jean-Christophe says (1) is the way to go ... This is arch/arm/mach-at91/gpio.c I guess. But this seems to call irq_create_mapping() for all IRQs on all gpiochips in at91_gpio_irq_setup() which is called by the board init code? Maybe I'm not following this :-/ I'll take a look over "my" GPIO drivers and see how I can make those a bit more elegant so as to set a good example. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
