Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754025Ab0FGXSn (ORCPT ); Mon, 7 Jun 2010 19:18:43 -0400 Received: from www.tglx.de ([62.245.132.106]:60047 "EHLO www.tglx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752772Ab0FGXSm (ORCPT ); Mon, 7 Jun 2010 19:18:42 -0400 Date: Tue, 8 Jun 2010 01:18:09 +0200 (CEST) From: Thomas Gleixner To: Esben Haabendal cc: Esben Haabendal , linuxppc-dev@ozlabs.org, Marc Zyngier , LKML , Ingo Molnar , joachim.eastwood@jotron.com, Peter Zijlstra , David Miller Subject: Re: [RFC][PATCH] irq: support IRQ_NESTED_THREAD with non-threaded interrupt handlers In-Reply-To: Message-ID: References: <1275686352.2970.2.camel@eha.doredevelopment.dk> <20100605151031.2d562268@hina.wild-wind.fr.eu.org> <1275914058.2818.8.camel@eha.doredevelopment.dk> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2743 Lines: 63 On Mon, 7 Jun 2010, Esben Haabendal wrote: > On Mon, Jun 7, 2010 at 5:06 PM, Thomas Gleixner wrote: > > > Maybe you understand now, why I was pretty sure upfront, that your > > approach was wrong even without knowing all the gory details ? :) > > I understand. There is a better solution, which is to use threaded > interrupts where needed. > > But I must confess that I am disappointed that you still fail to see > how the pca953x > patch actually eliminates the need for serialization. But I don't > think there is much > point in going on about that. I return the favour of being disappointed that you are still failing to accept that there is a fundamental difference between "it works in a particular case" and semantical correctness under all circumstances. There is no place for "it works in a particular case" in a kernel which runs on a gazillion of different devices unless you want to create a complete unmaintainable mess. The only way to avoid this is to be strict about semantics even if it seems unsensible for a particular case. Also I explained it to you in great length, that your patch violates the semantical guarantees of existing functions, but you ignore that completely. It's Open Source, go wild and change it for your particular case - but don't expect that I accept patches to the generic irq code which will cause _me_ predictable trouble as I have to deal with the fallout. Neither expect, that I ack patches to users of that code which are semantically wrong. Just for the record, the pca953x driver is broken vs. the local state protection anyway as the GPIO functions are not serialized against the interrupt controller functions. There is no magic which prevents that, neither on your system nor on any other. The GPIO function should take buslock when modifying local state and that's one of the reasons why buslock it is there and cannot go away. I'm anticipating that you are going to tell me that it does not matter on your particular powerpc combined with your usage pattern (i.e no GPIO users). And I tell you right away, that I'm not interested in this answer for well explained reasons. > Oh, I still think that the disable_irq_nosync documentaiton is misleading. > Functions that are allowed in a particular context should not call functions > that are not allowed to be called in that context. But now I know :-) As I said before: I agree and I'm happy to accept a patch to fix that documentation problem. Thanks, tglx -- 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/