From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755256AbbCEKxm (ORCPT ); Thu, 5 Mar 2015 05:53:42 -0500 Received: from foss.arm.com ([217.140.101.70]:56554 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754908AbbCEKxj (ORCPT ); Thu, 5 Mar 2015 05:53:39 -0500 Date: Thu, 5 Mar 2015 10:53:08 +0000 From: Mark Rutland To: Boris Brezillon Cc: Thomas Gleixner , Jason Cooper , Peter Zijlstra , "Rafael J. Wysocki" , Len Brown , Pavel Machek , "linux-pm@vger.kernel.org" , Wim Van Sebroeck , "linux-watchdog@vger.kernel.org" , Alessandro Zummo , "rtc-linux@googlegroups.com" , Greg Kroah-Hartman , Jiri Slaby , "linux-serial@vger.kernel.org" , Mike Turquette , "linux-kernel@vger.kernel.org" , Nicolas Ferre , Jean-Christophe Plagniol-Villard , Alexandre Belloni , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2 5/6] watchdog: at91sam9: request the irq with IRQF_NO_SUSPEND Message-ID: <20150305105308.GA13617@leverpostej> References: <1425287898-15093-1-git-send-email-boris.brezillon@free-electrons.com> <1425287898-15093-6-git-send-email-boris.brezillon@free-electrons.com> <20150304183809.GD22156@leverpostej> <20150305095306.3db98ac8@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150305095306.3db98ac8@bbrezillon> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.