On Wed, Jun 05, 2019 at 02:06:43PM +0000, Rasmus Villemoes wrote:
> This allows setting a default value for the watchdog.open_timeout
> commandline parameter via Kconfig.
>
> Some BSPs allow remote updating of the kernel image and root file
> system, but updating the bootloader requires physical access. Hence, if
> one has a firmware update that requires relaxing the
> watchdog.open_timeout a little, the value used must be baked into the
> kernel image itself and cannot come from the u-boot environment via the
> kernel command line.
>
> Being able to set the initial value in .config doesn't change the fact
> that the value on the command line, if present, takes precedence, and is
> of course immensely useful for development purposes while one has
> console acccess, as well as usable in the cases where one can make a
> permanent update of the kernel command line.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@xxxxxxxxx>
Reviewed-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> ---
> Documentation/watchdog/watchdog-parameters.txt | 8 ++++----
> drivers/watchdog/Kconfig | 9 +++++++++
> drivers/watchdog/watchdog_dev.c | 5 +++--
> 3 files changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
> index 32d3606caa65..ec919dc895ff 100644
> --- a/Documentation/watchdog/watchdog-parameters.txt
> +++ b/Documentation/watchdog/watchdog-parameters.txt
> @@ -11,10 +11,10 @@ modules.
> The watchdog core parameter watchdog.open_timeout is the maximum time,
> in seconds, for which the watchdog framework will take care of pinging
> a running hardware watchdog until userspace opens the corresponding
> -/dev/watchdogN device. A value of 0 (the default) means an infinite
> -timeout. Setting this to a non-zero value can be useful to ensure that
> -either userspace comes up properly, or the board gets reset and allows
> -fallback logic in the bootloader to try something else.
> +/dev/watchdogN device. A value of 0 means an infinite timeout. Setting
> +this to a non-zero value can be useful to ensure that either userspace
> +comes up properly, or the board gets reset and allows fallback logic
> +in the bootloader to try something else.
>
>
> -------------------------------------------------
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index ffe754539f5a..a8bd621e12f8 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -58,6 +58,15 @@ config WATCHDOG_HANDLE_BOOT_ENABLED
> the watchdog on its own. Thus if your userspace does not start fast
> enough your device will reboot.
>
> +config WATCHDOG_OPEN_TIMEOUT
> + int "Timeout value for opening watchdog device"
> + default 0
> + help
> + The maximum time, in seconds, for which the watchdog framework takes
> + care of pinging a hardware watchdog. A value of 0 means infinite. The
> + value set here can be overridden by the commandline parameter
> + "watchdog.open_timeout".
> +
> config WATCHDOG_SYSFS
> bool "Read different watchdog information through sysfs"
> help
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index e4b51db48f0e..334b810db2cf 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -88,7 +88,7 @@ static struct kthread_worker *watchdog_kworker;
> static bool handle_boot_enabled =
> IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
>
> -static unsigned open_timeout;
> +static unsigned open_timeout = CONFIG_WATCHDOG_OPEN_TIMEOUT;
>
> static bool watchdog_past_open_deadline(struct watchdog_core_data *data)
> {
> @@ -1214,4 +1214,5 @@ MODULE_PARM_DESC(handle_boot_enabled,
>
> module_param(open_timeout, uint, 0644);
> MODULE_PARM_DESC(open_timeout,
> - "Maximum time (in seconds, 0 means infinity) for userspace to take over a running watchdog (default=0)");
> + "Maximum time (in seconds, 0 means infinity) for userspace to take over a running watchdog (default="
> + __MODULE_STRING(CONFIG_WATCHDOG_OPEN_TIMEOUT) ")");
