On Monday, July 28, 2014 11:53:15 PM Rafael J. Wysocki wrote: > On Monday, July 28, 2014 02:33:41 PM Thomas Gleixner wrote: > > On Mon, 28 Jul 2014, Peter Zijlstra wrote: > > > On Sat, Jul 26, 2014 at 01:49:17PM +0200, Rafael J. Wysocki wrote:
[cut] > > So we are not going to make everything a single stupid flag and limit > > the usability of existing code. We rather go and try to remove the > > stupid flag before it becomes more wide spread. > > > > And we cannot treat the wakeup thing the same way as the > > IRQF_NO_SUSPEND flag, because there is hardware where the irq line > > must be disabled at the normal (non suspend) interrupt controller, and > > the wake mechanism tells the PM microcontroller to monitor the > > interrupt line and kick the machine back to life. > > > > So we need to very carefully look at all the existing cases instead of > > yelling crap and inflicting x86 specific horror on everyone. I said on > > friday, that I need to look at ALL use cases first and I meant it. > > Regardless of the use case, I don't think it is necessary to manipulate > the interrupt controller settings before the syscore_suspend stage, because > if an interrupt happens earlier, we need to handle it pretty much in a normal > way, unless it has been suspended. > > So I'd argue for not using anything like enable_irq_wake() that goes all > the way to the hardware in drivers. Instead, we could allow drivers to > mark interrupts as "set this up for system wakeup" and really do the setup > right before putting the platform into the final "suspended" state. And that > is totally independend of the IRQF_NO_SUSPEND thing. In addition to that we need the interrupt handler of the driver that requested the irq to be set up for system wakeup to be invoked after suspend_device_irqs() in case there are interrupts that should abort the suspend transition or we can lose a wakeup event. So whatever interface we decide to use it has to affect suspend/resume_device_irqs() pretty much in the same way as the IRQF_NO_SUSPEND flag. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/