| Message ID | 20190605140628.618-3-rasmus.villemoes@prevas.dk (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | watchdog: allow setting deadline for opening /dev/watchdogN | expand |
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@prevas.dk> Reviewed-by: Guenter Roeck <linux@roeck-us.net> > --- > 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) ")");
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) ")");
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@prevas.dk> --- Documentation/watchdog/watchdog-parameters.txt | 8 ++++---- drivers/watchdog/Kconfig | 9 +++++++++ drivers/watchdog/watchdog_dev.c | 5 +++-- 3 files changed, 16 insertions(+), 6 deletions(-)