Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip

From: Mark Rutland
Date: Fri Feb 20 2015 - 09:22:46 EST

Hi Boris,

On Wed, Feb 11, 2015 at 04:38:23PM +0000, Boris Brezillon wrote:


> For the list of impacted drivers, you can have a look at this series [1]
> (patches 2 to 5), and I'll take care of the testing part once every one
> has agreed on the solution ;-).
> [1]

Looking at those:

* The pmc looks like it could be a valid use of the new flag. It also
seems to function as an irqchip.

Do any of its child IRQs need to be handled during the suspend-resume
cycle? If so using IRQF_NO_SUSPEND would seem to be valid.

* atmel_serial seems to be intended to be used as a wakeup device (given
it calls device_set_wakeup_enable). Therefore it needs to call
enable_irq_wake, and when it does so it can share an IRQ with other
interrupts, just not IRQF_NO_SUSPEND interrupts.

None of the approaches thus far can fix the fundamental mismatch
between wakeup interrupts and IRQF_NO_SUSPEND interrupts.

* Similarly, rtc-at91rm9200 and rtc-at91sam9 are intended to be used as
wakeup devices. They call enable_irq_wake (though don't bother
checking the return value). They can share an IRQ with other
interrupts, just not IRQF_NO_SUSPEND interrupts.

* at91sam9_wdt seems to be fundamentally incompatible with suspend. If
the watchdog cannot be disabled, and you need to handle it during
suspend, then it needs to be a wakeup interrupt, not an
IRQF_NO_SUSPEND interrupt.

As far as I can see, the flag or virtual irqchip approaches only help
the PMC case, and even then might not be necessary. All the others seem
to be relying on guarantees the genirq layer don't provide, and fixing
that would mean moving them further from IRQF_NO_SUSPEND.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at