Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755258AbXK1TIY (ORCPT ); Wed, 28 Nov 2007 14:08:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759492AbXK1TIJ (ORCPT ); Wed, 28 Nov 2007 14:08:09 -0500 Received: from ms-smtp-03.nyroc.rr.com ([24.24.2.57]:38584 "EHLO ms-smtp-03.nyroc.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756823AbXK1TIG (ORCPT ); Wed, 28 Nov 2007 14:08:06 -0500 Date: Wed, 28 Nov 2007 14:04:41 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Russell King - ARM Linux cc: Remy Bohmer , Daniel Walker , RT , linux-kernel , ARM Linux Mailing List , Thomas Gleixner , Ingo Molnar Subject: Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever In-Reply-To: <20071128172509.GA30173@flint.arm.linux.org.uk> Message-ID: References: <3efb10970711260531x5e9f05acgfabdfa885a220192@mail.gmail.com> <3efb10970711260545i419a8352o4ca5248b10d81db5@mail.gmail.com> <1196176294.13982.58.camel@localhost.localdomain> <1196177122.23808.7.camel@imap.mvista.com> <1196178834.23808.11.camel@imap.mvista.com> <3efb10970711280638l3f57104y8cf9f2e58235c3@mail.gmail.com> <20071128172509.GA30173@flint.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1989 Lines: 53 On Wed, 28 Nov 2007, Russell King - ARM Linux wrote: > On Wed, Nov 28, 2007 at 03:38:11PM +0100, Remy Bohmer wrote: > > Hello Daniel, > > > > > * Note: The caller is expected to handle the ack, clear, mask and > > > * unmask issues if necessary. > > > So we shouldn't need any flow control unless there is some other > > > factors.. > > > > This comment can be misinterpreted, I think. Who is assumed to be the > > caller in this context? The 2 other routines in the driver that > > actually do the unmasking stuff besides only calling this routine? Is > > it allowed to call it directly or should it always be done through a > > wrapper that does all these special things? > > The whole point of this simple handler is to accomodate interrupts such > as those found on the Neponset board. > > There, you have a status register in a CPLD but no enable/disable > registers. The status register tells you whether the SA1111, ethernet > or 'USAR' chip asserted its interrupt. > > However, as there is no way to disable the sources, this situation has > to be handled carefully - the function decoding the interrupt source > needs to mask and unmask the _parent_ interrupt itself, and it's > exactly that which the comment is directed towards. > > See neponset_irq_handler(). > > The simple IRQ handler is not meant for anything other than that really > simple implementation. If people have been using it with interrupts > which can be individually masked and unmasked, that's where the bug is. > They should be using one of the other handlers. > Russell, Thanks for the reply and this nice explanation. I'm taking this as a NACK. Daniel or Remy, could you find the offending users and make send patches to fix them. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/