On 17/03/16 15:02, Thomas Gleixner wrote: > On Thu, 17 Mar 2016, Jon Hunter wrote: >> /** >> * struct irq_chip - hardware interrupt chip descriptor >> * >> + * @parent: pointer to associated device > > That's really a bad name. parent suggests that this is a parent interrupt chip > and your explanation sucks as well. What's an associated device? Network card? Linus, can you re-iterate your concerns here about just using 'dev' for the name? >> #include <linux/irqdesc.h> >> #include <linux/kernel_stat.h> >> +#include <linux/pm_runtime.h> >> >> #ifdef CONFIG_SPARSE_IRQ >> # define IRQ_BITMAP_BITS (NR_IRQS + 8196) >> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c >> index b2a93a37f772..65878e7c7c82 100644 >> --- a/kernel/irq/manage.c >> +++ b/kernel/irq/manage.c >> @@ -1114,6 +1114,10 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new) >> if (!try_module_get(desc->owner)) >> return -ENODEV; >> >> + ret = irq_chip_pm_get(&desc->irq_data); >> + if (ret < 0) >> + goto out_mput; > > So this call nests inside the chip_bus_lock() region. Is that intentional? Hmm ... I was trying to simplify the call paths, but yes I think it would be safer to move outside. Ok, will fix that. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
