Hi Uwe, On 08/04/2015 08:38 AM, Uwe Kleine-König wrote:
Hello, On Mon, Aug 03, 2015 at 07:13:30PM -0700, Guenter Roeck wrote:For some watchdogs, the hardware timeout is fixed, and the watchdog driver depends on the watchdog core to handle the actual timeout. In this situation, the watchdog driver might only set the 'timeout' variable but do nothing else. This can as well be handled by the infrastructure, so make the set_timeout callback optional. If WDIOF_SETTIMEOUT is configured but the .set_timeout callback is not available, update the timeout variable in the infrastructure code. Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx> --- Documentation/watchdog/watchdog-kernel-api.txt | 4 ++++ drivers/watchdog/watchdog_dev.c | 9 ++++++--- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt index 7fda3c86cf46..2f1a4ad7e565 100644 --- a/Documentation/watchdog/watchdog-kernel-api.txt +++ b/Documentation/watchdog/watchdog-kernel-api.txt @@ -178,6 +178,10 @@ they are supported. These optional routines/operations are: because the watchdog does not necessarily has a 1 second resolution). (Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the watchdog's info structure). + If the watchdog driver does not have to perform any action but setting the + timeout value of the watchdog_device, this callback can be omitted. + If set_timeout is not provided but WDIOF_SETTIMEOUT is set, the watchdog + infrastructure updates the timeout value of the watchdog_device internally.What is the semantic of struct watchdog_device.timeout? Is it the corrently configured hw-timeout? Or what userspace sees? In the former case timeout shouldn't be updated. And in the latter case it's wrong that the worker thread uses this member to determine the needed rate for it's auto pinging.
.timeout is what user-space sees, but it is also what may be configured into the hardware, depending on the value of max_hw_timeout and on the driver. For example, if timeout = 5s and max_hw_timeout = 6000ms, the driver would (or might) configure the _current_ hardware timeout to 5s. The worker would not be activated. If, on the other side, timeout = 10s and max_hw_timeout = 6000ms, the driver would configure the hardware timeout to 6s, the worker would send a heartbeat every 3 seconds, and user space would be expected to send a heartbeat every 5 seconds or so (assuming it uses timeout/2 to determine when to send heartbeats). Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
