Hi Boris, I'd missed the fact that this was for SW watchdog as opposed to HW watchdog, which may explain my confusion. [...] > > > err = request_irq(wdt->irq, wdt_interrupt, > > > - IRQF_SHARED | IRQF_IRQPOLL, > > > + IRQF_SHARED | IRQF_IRQPOLL | > > > + IRQF_NO_SUSPEND, > > > > I'm a little confused by this. What happens if the watchdog fires when > > we're actually in the suspended state (when IRQF_NO_SUSPEND interrupts > > aren't guaranteed to be delivered). > > It reboot the system. Is the timer we use to ping the watchdog guaranted to result in a wakeup before an interrupt will be triggered? If so, then I think we're ok. If not, then don't we need to clear a potentially pending watchdog irq at resume time so at to not immediately reboot the machine? I couldn't see any logic to that effect in the driver. Regardless, if the only reason we care about taking the interrupt during the suspend/resume phases is due to the timer sharing the IRQ, then shouldn't we be using IRQF_COND_SUSPEND? 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
