| Message ID | 1473170343-16853-1-git-send-email-marc.zyngier@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Sep 6, 2016 at 3:59 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: > Using a default trigger is a bad idea if using DT to configure > interrupts, as the device's interrupt specifier will always contain > the trigger configuration. > > Let's warn about that particular situation, and revert to not > having a default. Hopefully, the couple of drivers still using > this feature will quickly be fixed. > > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Patch applied. This is a good way to get rid of this madness. > + /* > + * Specifying a default trigger is a terrible idea if DT is > + * used to configure the interrupts, as you may end-up with > + * conflicting triggers. Tell the user, and reset to NONE. > + */ > + if (WARN_ON(of_node && type != IRQ_TYPE_NONE, > + "%s: Ignoring %d default trigger\n", of_node->full_name)) > + type = IRQ_TYPE_NONE; I *strongly* suspect this is bad also when using ACPI. Would the GPIO ACPI people devise a patch on top of this to emit the same warning for the ACPI usecase? Yours, Linus Walleij
On Thu, Sep 08, 2016 at 12:13:27AM +0200, Linus Walleij wrote: > On Tue, Sep 6, 2016 at 3:59 PM, Marc Zyngier <marc.zyngier@arm.com> wrote: > > > Using a default trigger is a bad idea if using DT to configure > > interrupts, as the device's interrupt specifier will always contain > > the trigger configuration. > > > > Let's warn about that particular situation, and revert to not > > having a default. Hopefully, the couple of drivers still using > > this feature will quickly be fixed. > > > > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> > > Patch applied. This is a good way to get rid of this madness. > > > + /* > > + * Specifying a default trigger is a terrible idea if DT is > > + * used to configure the interrupts, as you may end-up with > > + * conflicting triggers. Tell the user, and reset to NONE. > > + */ > > + if (WARN_ON(of_node && type != IRQ_TYPE_NONE, > > + "%s: Ignoring %d default trigger\n", of_node->full_name)) > > + type = IRQ_TYPE_NONE; > > I *strongly* suspect this is bad also when using ACPI. I agree. > Would the GPIO ACPI people devise a patch on top of this > to emit the same warning for the ACPI usecase? Yup, I'll make a patch for ACPI next week.
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 53ff25a..e467ad7 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1617,6 +1617,15 @@ int _gpiochip_irqchip_add(struct gpio_chip *gpiochip, if (gpiochip->of_node) of_node = gpiochip->of_node; #endif + /* + * Specifying a default trigger is a terrible idea if DT is + * used to configure the interrupts, as you may end-up with + * conflicting triggers. Tell the user, and reset to NONE. + */ + if (WARN_ON(of_node && type != IRQ_TYPE_NONE, + "%s: Ignoring %d default trigger\n", of_node->full_name)) + type = IRQ_TYPE_NONE; + gpiochip->irqchip = irqchip; gpiochip->irq_handler = handler; gpiochip->irq_default_type = type;
Using a default trigger is a bad idea if using DT to configure interrupts, as the device's interrupt specifier will always contain the trigger configuration. Let's warn about that particular situation, and revert to not having a default. Hopefully, the couple of drivers still using this feature will quickly be fixed. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> --- drivers/gpio/gpiolib.c | 9 +++++++++ 1 file changed, 9 insertions(+)