Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753349AbbERObH (ORCPT <rfc822;w@1wt.eu>);
	Mon, 18 May 2015 10:31:07 -0400
Received: from www.linutronix.de ([62.245.132.108]:49443 "EHLO
	Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751749AbbERObF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 18 May 2015 10:31:05 -0400
Date: Mon, 18 May 2015 16:31:10 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: "Grygorii.Strashko@linaro.org" <grygorii.strashko@linaro.org>,
        Ingo Molnar <mingo@redhat.com>, Roger Quadros <rogerq@ti.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Alexandre Courbot <gnurou@gmail.com>,
        "linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
        "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Calling irq_set_irq_wake() from .set_irq_wake()? (was: Re:
 [PATCH] gpio: pcf875x: Revert "gpio: pcf857x: Propagate wake-up setting to
 parent irq controller")
In-Reply-To: <CAMuHMdXYPcQNCHhGa5kC8omtBw_O=Ua+rRJ+gh3tc6dY0oC5JA@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1505181626060.4225@nanos>
References: <CAMuHMdXYPcQNCHhGa5kC8omtBw_O=Ua+rRJ+gh3tc6dY0oC5JA@mail.gmail.com>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Linutronix-Spam-Score: -1.0
X-Linutronix-Spam-Level: -
X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required,  ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1981
Lines: 47

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: [<c0096ebc>] __irq_get_desc_lock+0x48/0x88
> >>> [   30.663722]
> >>> [   30.663722] but task is already holding lock:
> >>> [   30.663734]  (class){......}, at: [<c0096ebc>] __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.

> >> 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.
 
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/