一、设备IRQ的suspend和resume
本小节主要解决这样一个问题：在系统休眠过程中，如何suspend设备中断（IRQ）？在从休眠中唤醒的过程中，如何resume设备IRQ？
一般而言，在系统suspend过程的后期，各个设备的IRQ (interrupt request line)会被disable掉。具体的时间点是在各个设备的late suspend阶段之后。代码如下（删除了部分无关代码）：
static int suspend_enter(suspend_state_t state, bool *wakeup)
{……
error = dpm_suspend_late(PMSG_SUSPEND);－－－－－late suspend阶段
error = platform_suspend_prepare_late(state);
下面的代码中会disable各个设备的irq
error = dpm_suspend_noirq(PMSG_SUSPEND);－－－－进入noirq的阶段
error = platform_suspend_prepare_noirq(state);
……
}在dpm_suspend_noirq函数中，会针对系统中的每一个device，依次调用device_suspend_noirq来执行该设备noirq情况下的suspend callback函数，当然，在此之前会调用suspend_device_irqs函数来disable所有设备的irq。
之所以这么做，其思路是这样的：在各个设备驱动完成了late suspend之后，按理说这些已经被suspend的设备不应该再触发中断了。如果还有一些设备没有被正确的suspend，那么我们最好的策略是mask该设备的irq，从而阻止中断的递交。此外，在过去的代码中（指interrupt handler），我们对设备共享IRQ的情况处理的不是很好，存在这样的问题：在共享IRQ的设备们完成suspend之后，如果有中断触发，这时候设备驱动的interrupt handler并没有准备好。在有些场景下，interrupt handler会访问已经suspend设备的IO地址空间，从而导致不可预知的issue。这些issue很难debug，因此，我们引入了suspend_device_irqs()以及设备noirq阶段的callback函数。
系统resume过程中，在各个设备的early resume过程之前，各个设备的IRQ会被重新打开，具体代码如下（删除了部分无关代码）：
static int suspend_enter(suspend_state_t state, bool *wakeup)
{……
platform_resume_noirq(state);－－－－首先执行noirq阶段的resume
dpm_resume_noirq(PMSG_RESUME);－－－－－－在这里会恢复irq，然后进入early resume阶段
platform_resume_early(state);
dpm_resume_early(PMSG_RESUME);
……}在dpm_resume_noirq函数中，会调用各个设备驱动的noirq callback，在此之后，调用resume_device_irqs函数，完成各个设备irq的enable。
二、关于IRQF_NO_SUSPEND Flag
当然，有些中断需要在整个系统的suspend-resume过程中（包括在noirq阶段，包括将nonboot CPU推送到offline状态以及系统resume后，将其重新设置为online的阶段）保持能够触发的状态。一个简单的例子就是timer中断，此外IPI以及一些特殊目的设备中断也需要如此。
在中断申请的时候，IRQF_NO_SUSPEND flag可以用来告知IRQ subsystem，这个中断就是上一段文字中描述的那种中断：需要在系统的suspend-resume过程中保持enable状态。有了这个flag，suspend_device_irqs并不会disable该IRQ，从而让该中断在随后的suspend和resume过程中，保持中断开启。当然，这并不能保证该中断可以将系统唤醒。如果想要达到唤醒的目的，请调用enable_irq_wake。
需要注意的是：IRQF_NO_SUSPEND flag影响使用该IRQ的所有外设（一个IRQ可以被多个外设共享，不过ARM中不会这么用）。如果一个IRQ被多个外设共享，并且各个外设都注册了对应的interrupt handler，如果其一在申请中断的时候使用了IRQF_NO_SUSPEND flag，那么在系统suspend的时候（指suspend_device_irqs之后，按理说各个IRQ已经被disable了），所有该IRQ上的各个设备的interrupt handler都可以被正常的被触发执行，即便是有些设备在调用request_irq(或者其他中断注册函数)的时候没有设定IRQF_NO_SUSPEND flag。正因为如此，我们应该尽可能的避免同时使用IRQF_NO_SUSPEND 和IRQF_SHARED这两个flag。
三、系统中断唤醒接口：enable_irq_wake() 和 disable_irq_wake()
有些中断可以将系统从睡眠状态中唤醒，我们称之“可以唤醒系统的中断”，当然，“可以唤醒系统的中断”需要配置才能启动唤醒系统这样的功能。这样的中断一般在工作状态的时候就是作为普通I/O interrupt出现，只要在准备使能唤醒系统功能的时候，才会发起一些特别的配置和设定。
有些中断可以将系统从睡眠状态中唤醒，我们称之“可以唤醒系统的中断”，当然，“可以唤醒系统的中断”需要配置才能启动唤醒系统这样的功能。这样的中断一般在工作状态的时候就是作为普通I/O interrupt出现，只要在准备使能唤醒系统功能的时候，才会发起一些特别的配置和设定。
外设的中断信号被送到“通用的中断信号处理模块”和“特定中断信号接收模块”。正常工作的时候，我们会turn on“通用的中断信号处理模块”的处理逻辑，而turn off“特定中断信号接收模块” 的处理逻辑。但是，在系统进入睡眠状态的时候，有可能“通用的中断信号处理模块”已经off了，这时候，我们需要启动“特定中断信号接收模块”来接收中断信号，从而让系统suspend-resume模块（它往往是suspend状态时候唯一能够工作的HW block了）可以正常的被该中断信号唤醒。一旦唤醒，我们最好是turn off“特定中断信号接收模块”，让外设的中断处理回到正常的工作模式，同时，也避免了系统suspend-resume模块收到不必要的干扰。
IRQ子系统提供了两个接口函数来完成这个功能：enable_irq_wake()函数用来打开该外设中断线通往系统电源管理模块（也就是上面的suspend-resume模块）之路，另外一个接口是disable_irq_wake()，用来关闭该外设中断线通往系统电源管理模块路径上的各种HW block。
调用了enable_irq_wake会影响系统sus