From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [PATCH 0/3] GPIO support for BRCMSTB Date: Tue, 2 Jun 2015 17:28:31 +0100 Message-ID: <20150602162830.GI2067@n2100.arm.linux.org.uk> References: <1430901477-10678-1-git-send-email-gregory.0xf0@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Walleij Cc: Gregory Fong , "linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Alexandre Courbot , bcm-kernel-feedback-list , Brian Norris , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Florian Fainelli , Ian Campbell , Kumar Gala , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Mark Rutland , Pawel Moll , Rob Herring List-Id: devicetree@vger.kernel.org On Tue, Jun 02, 2015 at 11:05:21AM +0200, Linus Walleij wrote: > ... and have the > IRQ handler return IRQ_NONE if the IRQ comes from this > bank, or IRQ_HANDLED if it has handled an IRQ from its own > space. I'm not sure that's worded correctly or not, but... fwiw, all IRQ handlers _should_ be returning IRQ_NONE if the IRQ does not belong to them whether or not they're shared handlers. That is so the kernel can detect stuck IRQs and report that fact, rather than just locking up silently. ARM CPUs make no progress when the IRQ to them is permanently asserted, so a stuck IRQ can be rather problematical. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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