[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150307105953.GC28436@gradator.net>
Date: Sat, 7 Mar 2015 11:59:53 +0100
From: Sylvain Rochet <gradator@...dator.net>
To: Pavel Machek <pavel@....cz>
Cc: Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
Alessandro Zummo <a.zummo@...ertech.it>,
Mike Turquette <mturquette@...aro.org>,
Jason Cooper <jason@...edaemon.net>,
"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
Len Brown <len.brown@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Nicolas Ferre <nicolas.ferre@...el.com>,
Wim Van Sebroeck <wim@...ana.be>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
Thomas Gleixner <tglx@...utronix.de>,
Jiri Slaby <jslaby@...e.cz>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>
Subject: Re: [PATCH v2 5/6] watchdog: at91sam9: request the irq with
IRQF_NO_SUSPEND
Hello,
On Sat, Mar 07, 2015 at 11:39:39AM +0100, Pavel Machek wrote:
> On Sat 2015-03-07 11:20:56, Sylvain Rochet wrote:
> > Hello,
> >
> > On Sat, Mar 07, 2015 at 10:18:46AM +0100, Peter Zijlstra wrote:
> > > On Thu, Mar 05, 2015 at 11:53:08AM +0000, Mark Rutland wrote:
> > > > If everyone else is happy with this using IRQF_NO_SUSPEND for now then
> > > > don't let my comments above block this patch.
> > >
> > > Yeah, I'm really not happy with NO_SUSPEND + enable_irq_wake().
> > >
> > > I really want that combo to BUG/WARN -- esp. since there's so much cargo
> > > culted crap out there.
> > >
> > > We should make robust interfaces, not randomly toggle flags until it
> > > mostly works by accident rather than by design -- which is what this
> > > feels like.
> > >
> > > And while I appreciate the watchdog use-case; I think the easiest
> > > solution for now is to simply disable the wathdog over suspend until
> > > we've come up with something that makes sense.
> > >
> > > As it is, you need to 'suspend' the watchdog at some point anyhow; you
> > > don't want that thing to wake you from whatever suspend state you're in.
> >
> > The Atmel watchdog can't be stopped once it's started. This is actually
> > very useful so we can reset if suspend or resume failed, the only
> > drawback is that you have to wake up from time to time (e.g. by using
> > the RTC/RTT) to clear the watchdog and then go back to sleep ASAP.
>
> Yeah. So you do "echo mem > /sys/power/state", and few seconds/minutes
> after watchdog kills the system. But you did not ask for dead system,
> you asked for suspend.
Yeah, that's why I'm setting the RTC/RTT in the pm_enter() callback on
our products. On wake-up I'm checking if we woke up using the RTC/RTT in
the pm_suspend_again() callback, if true we clear the watchdog and we go
back to sleep. This can't easily be mainlined because it adds
RTC/RTT/WDT calls from PM code, which will not be accepted anyway.
> And while that behaviour is useful for you, I don't think it is
> exactly useful behaviour, nor it is the behaviour user would expect.
I agree, but it still can't be stopped, IMHO users wanting to suspend
without being protected by the watchdog during suspend and resume should
just don't use the hardware watchdog at all, they are already missing
the watchdog in a tricky area where the kernel can fail more than
anywhere else, the software watchdog should be fine as well for them.
Sylvain
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists