From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758176AbYHZKst (ORCPT ); Tue, 26 Aug 2008 06:48:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753851AbYHZKsl (ORCPT ); Tue, 26 Aug 2008 06:48:41 -0400 Received: from s200aog16.obsmtp.com ([207.126.144.130]:56119 "EHLO s200aog16.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752937AbYHZKsl (ORCPT ); Tue, 26 Aug 2008 06:48:41 -0400 X-Greylist: delayed 2013 seconds by postgrey-1.27 at vger.kernel.org; Tue, 26 Aug 2008 06:48:40 EDT Subject: Re: [PATCH] genirq: irq_chip->startup() usage in setup_irq and set_irq_chained handler From: Pawel MOLL To: benh@kernel.crashing.org Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Thomas Gleixner In-Reply-To: <1219531395.21386.200.camel@pasglop> References: <1219313656.31630.89.camel@bri1004.bri.st.com> <1219416584.31630.639.camel@bri1004.bri.st.com> <20080823160859.GE27974@elte.hu> <1219531395.21386.200.camel@pasglop> Content-Type: text/plain; charset=utf-8 Date: Tue, 26 Aug 2008 11:14:36 +0100 Message-Id: <1219745676.16078.219.camel@bri1004.bri.st.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > The second change is a significant semantic change. I wouldn't be > surprised if I have cases that rely (or work around) the lack of > startup() in set_irq_chained_handler(). I'll have to dbl check things > next week. Let me briefly explain my situation. I have a main interrupt controller which provides startup() and unmask/mask() functions. The first one is rather expensive (as the controller itself is... hmmm... complicated ;-), the second - very cheap. And that is how I understand the different "levels" of interrupt access - startup() should be called once, somewhere during request_irq(), (un)masking may be used frequently. And one of the interrupt is generated by hardware PIO controller. The idea was obvious - register a chained handler, which decodes the PIO controller state and generates a interrupt, which number may be obtained by gpio_to_irq(). Sounds simple, doesn't it? :-) And in that moment the problem raised its ugly head - the interrupt controller's startup() was never called for the PIO interrupt (as there was no request_irq()), so the hardware wasn't configured properly and... well... bad things were happening ;-) So unless I totally misunderstood the meaning of irq_chip callbacks, I believe the startup() should be called in set_irq_chained_handler(). Regards Paweł