linux-kernel - Re: [PATCHv3 3/4] watchdog: rti-wdt: attach to running watchdog during probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 14 Jul 2020 07:42:28 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Tero Kristo <t-kristo@...com>, wim@...ux-watchdog.org,
        linux-watchdog@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, jan.kiszka@...mens.com
Subject: Re: [PATCHv3 3/4] watchdog: rti-wdt: attach to running watchdog
 during probe

On 7/14/20 12:13 AM, Tero Kristo wrote:
[ ... ]

>>> Well, you can re-program it but... It does not take effect until next window starts, so basically we need to take care of the currently running window anyways after which re-programming it doesn't make much sense anymore. And handling the switch from one setup to next would add extra complexity.
>>>
>>
>> Seems to me that hardware team really made an effort to make the
>> watchdog as difficult to program as possible :-(.
> 
> Yea, it is surprisingly difficult to program... when watchdogs in principle are extremely simple pieces of HW. This claims to be some automotive grade watchdog, which means it has the window in place.
> 

We are getting a bit off topic, but that almost sounds like
"automotive" translates to "it must be hard to program".
I can not think of a valid reason for such a window, no matter
the circumstances. Either case, dealing with the window in the
kernel in that situation (ie if some specification states that
the window must exist) would be the wrong solution and circumvent
the reason for having it in the first place.

Not that this matters here, of course. I am just wondering what the impact
would be if the driver is indeed used in such an application. For example,
some compliance test code might try to ping the watchdog outside the window
to test its reaction. Such test code would fail if the ping is delayed
by the kernel.

Guenter