On Mon, Nov 18, 2013 at 04:21:06PM +0200, ivan.khoronzhuk wrote: > On 11/17/2013 04:24 AM, Guenter Roeck wrote: > > On 11/06/2013 03:32 AM, ivan.khoronzhuk wrote: > >> When watchdog timer is expired we can know about it thought > > > > thought -> through or with > > > > Ok > > >> GET_STATUS ioctl option. > >> > >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@xxxxxx> > >> --- > >> drivers/watchdog/davinci_wdt.c | 13 +++++++++++++ > >> 1 file changed, 13 insertions(+) > >> > >> diff --git a/drivers/watchdog/davinci_wdt.c > >> b/drivers/watchdog/davinci_wdt.c > >> index 6cbf2e1..a371b2d 100644 > >> --- a/drivers/watchdog/davinci_wdt.c > >> +++ b/drivers/watchdog/davinci_wdt.c > >> @@ -144,6 +144,18 @@ static unsigned int > >> davinci_wdt_get_timeleft(struct watchdog_device *wdd) > >> return wdd->timeout - timer_counter; > >> } > >> > >> +static unsigned int davinci_wdt_status(struct watchdog_device *wdd) > >> +{ > >> + u32 val; > >> + struct davinci_wdt_device *davinci_wdt = watchdog_get_drvdata(wdd); > >> + > >> + val = ioread32(davinci_wdt->base + WDTCR); > >> + if (val & WDFLAG) > >> + return WDIOF_CARDRESET; > >> + > > "Card previously reset the CPU" > > > > Is this really accurate / correct ? > > > > My understanding is that the status is supposed to return the reason for > > a previous reset/reboot, > > not the curent condition. > > > > Actually it is not so good correlate with the purpose, but I grasped > several examples like watchdog/pcwd.c; watchdog/w83977f_wdt.c; > watchdog/of_xilinx_wdt.c and saw that I can use it in meaning "the card initiated reset. > After the WDT is overflowed it sets WDFLAG, so I can use it. > It is more useful while debugging and if it is doubtful I can drop it. > The usual reaction to a watchdog timer event is a reset, so I am somewhat doubtful if this is of any use in practice, other than maybe to show that it isn't working. Anyway, I always dislike it when people point out other wrong usages of an API (or anything, really) as argument to do the same. Speeding isn't legal either, no matter how many people do it. FWIW, the wrong usages you pointed out should in my opinion be removed, and if Wim agrees I'll be happy to submit patches to do it. If you need debugging information, there is always debugfs. There should be no need to hijack an API which is supposed to be used for something else. Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html