On 5/29/2014 9:37 PM, Linus Walleij wrote: > On Tue, May 27, 2014 at 2:04 PM, Grygorii Strashko > <grygorii.strashko@xxxxxx> wrote: >> On 05/27/2014 11:46 AM, Mika Westerberg wrote: (...) > > My idea is that you should call gpiochip_add() *first* and then > add the IRQs to the chip. In succession. > > Rationale: with dynamic GPIO numbers, gpio_to_irq() > cannot reasonably be working before the gpiochip is added, > so it should be added first, then the irqchip. Since irq_to_gpio() > is *NOT* to be used (rather obliterated), this is the sequence > we mandate. > > This is how the new irqchip helpers work by the way. As I > introduce this to more and more drivers it will look more and > more like this. And attack patches tagged RFT switching the > semantics of drivers are appreciated. > > Yours, > Linus Walleij > Thanks. I'll use this sequence during probe(). (...) cg->regmap = pmic->regmap; retval = gpiochip_add(&cg->chip); if (retval) { dev_warn(&pdev->dev, "add gpio chip error: %d\n", retval); return ret; } gpiochip_irqchip_add(&cg->chip, &crystalcove_irqchip, 0, handle_simple_irq, IRQ_TYPE_NONE); retval = request_threaded_irq(irq, NULL, crystalcove_gpio_irq_handler, IRQF_ONESHOT, KBUILD_MODNAME, cg); if (retval) { dev_warn(&pdev->dev, "request irq failed: %d\n", retval); WARN_ON(gpiochip_remove(&cg->chip)); return retval; } return 0; } Is the code above OK? But this code will trigger a crash in gpiolib-acpi. Currently at the end of gpiochip_add(), it calls: gpiochip_add() -> acpi_gpiochip_add() -> acpi_gpiochip_request_interrupts() acpi_gpiochip_request_interrupts() needs ->to_irq to work. Without having called gpiochip_irqchip_add() already, this will be NULL: if (!chip->to_irq) return; <-- It will return here. INIT_LIST_HEAD(&acpi_gpio->events); In the tear down path, acpi_gpiochip_free_interrupts() will find to_irq is no longer NULL, then it will walk an uninitialized list. So, should this be fixed in gpiolib-acpi? Best Regards Lejun -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html