On Thu, Apr 11, 2013 at 10:30 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 04/10/2013 03:28 PM, Linus Walleij wrote: >> So the only reason I'm rambing on about this is that it breaks the > > I'm not sure I understand this paragraph; what is "it" in the line above. > > If "it" is this patch, then should "breaks" be re-establishes? No I'm replying to Javier Martinez Canillas mail in this thread: http://marc.info/?l=linux-arm-kernel&m=136334655902407&w=2 which is stating a question to grand, and contains the below hunk: > +static int gpio_irq_request(struct irq_data *d) > +{ > + struct gpio_bank *bank = irq_data_get_irq_chip_data(d); > + > + return gpio_request(irq_to_gpio(bank, d->irq), "gpio-irq"); > +} irq_to_gpio(). Notice that. not my_funny_driver_irq_to_gpio(). It's the same thing you mention below: > If I recall the patch I'm replying to correctly, the idea was to add an > "IRQ request" operation that would (internally to the GPIO/IRQ driver > itself) map IRQ->GPIO, and call gpio_request(). That would then prevent > exactly the situation you mention above. So the above does not look like it's internal to the driver does it? I think this is irq_to_gpio sneaking back in, and requiring that every driver of this sort follow the same design pattern. And then maybe you see my persistance ... are we talking about different things? So I'd be happy with something local to the driver, foo_irq_to_gpio() and that we also back out a bit and see what the subsystem can do to avoid this kind of code having to be duplicated everywhere, that's all. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
