Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753377AbbEROxC (ORCPT ); Mon, 18 May 2015 10:53:02 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:33825 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752556AbbEROww (ORCPT ); Mon, 18 May 2015 10:52:52 -0400 From: "Grygorii.Strashko@linaro.org" X-Google-Original-From: "Grygorii.Strashko@linaro.org" Message-ID: <5559FCC0.2050302@linaro.org> Date: Mon, 18 May 2015 17:52:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Thomas Gleixner , Geert Uytterhoeven CC: Ingo Molnar , Roger Quadros , Linus Walleij , Alexandre Courbot , "linux-gpio@vger.kernel.org" , "linux-omap@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: Calling irq_set_irq_wake() from .set_irq_wake()? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2650 Lines: 71 On 05/18/2015 05:31 PM, Thomas Gleixner wrote: > On Sun, 17 May 2015, Geert Uytterhoeven wrote: >>>>> At least the recursive locking message no longer appears after the revert. >>>>> >>>>> [ 30.591905] PM: Syncing filesystems ... done. >>>>> [ 30.623060] Freezing user space processes ... (elapsed 0.003 seconds) done. >>>>> [ 30.634470] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. >>>>> [ 30.658288] sd 0:0:0:0: [sda] Synchronizing SCSI cache >>>>> [ 30.663678] >>>>> [ 30.663681] ============================================= >>>>> [ 30.663683] [ INFO: possible recursive locking detected ] >>>>> [ 30.663688] 4.1.0-rc3 #1115 Not tainted >>>>> [ 30.663693] --------------------------------------------- >>>>> [ 30.663697] suspend.sh/2319 is trying to acquire lock: >>>>> [ 30.663719] (class){......}, at: [] __irq_get_desc_lock+0x48/0x88 >>>>> [ 30.663722] >>>>> [ 30.663722] but task is already holding lock: >>>>> [ 30.663734] (class){......}, at: [] __irq_get_desc_lock+0x48/0x88 >>>> >>>> Does this mean .set_irq_wake() cannot call irq_set_irq_wake()? > > It can call it, if it's guaranteed that this wont deadlock. > > To tell lockdep that you sure about that, you need to set a different > lock class for the child interrupts. irq_set_lockdep_class() is what > you want to use here. Hm. Seems we already have corresponding call in gpiochip_irq_map: static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, irq_hw_number_t hwirq) { struct gpio_chip *chip = d->host_data; irq_set_chip_data(irq, chip); irq_set_lockdep_class(irq, &gpiochip_irq_lock_class); ^^^^ commit e45d1c80c0eee88e82751461e9cac49d9ed287bc Author: Linus Walleij Date: Tue Apr 22 14:01:46 2014 +0200 gpio: put GPIO IRQs into their own lock clas added in Kernel v3.16 Roger, can you confirm that you've observed this issue with latest kernel, pls? > >>>> Many GPIO drivers do that, as they need to propagate wake-up state to the >>>> parent interrupt controller? >>> >>> As I remember, there was similar problem, so I found corresponding patch (just FYI) >>> >>> ab2b926 mfd: Fix twl6030 lockdep recursion warning on setting wake IRQs >>> >>> Not sure such kind of solution is the best choice ( >> >> That looks like a convoluted solution... > > Indeed. See above. -- regards, -grygorii -- 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/