> >> > We seem to be conflating some related properties: > >> > > >> > [a] The IRQ will be left unmasked. > >> > [b] The IRQ will be handled immediately when taken. > >> > [c] The IRQ will wake the system from suspend. [...] > > Considering that the use-case of a watchdog is to alert us to something > > going hideously wrong in the kernel, we want to handle the IRQ after > > executing the smallest amount of kernel code possible. For that, they > > need to have their handlers to be called "immediately" outside of the > > arch_suspend_disable_irqs() ... arch_suspend_enable_irqs() window, and > > need to be enabled during suspend to attempt to catch bad wakeup device > > configuration. > > > > I think it's possible (assuming the caveats on [b] above) to provide > > [a,b,c] for this case. > > OK > > But in this case the request_irq() passing IRQF_NO_SUSPEND *and* requiring > enable_irq_wake() in addition to that needs a big fat comment explaining the > whole thing or we'll forget about the gory details at one point and no one will > know what's going on in there. Agreed. I'd expect an IRQF_SW_WATCHDOG or something to that effect should also be required for that case. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html