On 05/18/2015 05:31 PM, Thomas Gleixner wrote:

On Sun, 17 May 2015, Geert Uytterhoeven wrote:

quoted

quoted

quoted

quoted

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.

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 [off-list ref]
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?

quoted

quoted

quoted

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