Fwd: [PATCH 4/8] watchdog: davinci: add GET_STATUS option support

ivan.khoronzhuk ivan.khoronzhuk at ti.com
Mon Nov 18 11:28:05 EST 2013


On 11/18/2013 06:24 PM, Guenter Roeck wrote:
> 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 at ti.com>
>>>> ---
>>>>    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
>

I'll drop it

-- 
Regards,
Ivan Khoronzhuk



More information about the linux-arm-kernel mailing list