From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: [PATCH 08/15] genirq: Add runtime power management support for IRQ chips Date: Thu, 17 Mar 2016 15:46:08 +0000 Message-ID: <56EAD140.3090709@nvidia.com> References: <1458224359-32665-1-git-send-email-jonathanh@nvidia.com> <1458224359-32665-9-git-send-email-jonathanh@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Thomas Gleixner , Linus Walleij Cc: Jason Cooper , Marc Zyngier , =?UTF-8?Q?Beno=c3=aet_Cousson?= , Tony Lindgren , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Stephen Warren , Thierry Reding , Kevin Hilman , Geert Uytterhoeven , Grygorii Strashko , Lars-Peter Clausen , linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org 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 >> #include >> +#include >> >> #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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html