| Message ID | 20210218163200.1154812-1-f.suligoi@asem.it |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] watchdog: wdat: add param. to start wdog on module insertion | expand |
Hi, On Thu, Feb 18, 2021 at 05:32:00PM +0100, Flavio Suligoi wrote: > Add the parameter "start_enable" to start the watchdog > directly on module insertion. > > In an embedded system, for some applications, the watchdog > must be activated as soon as possible. > > In some embedded x86 boards the watchdog can be activated > directly by the BIOS (with an appropriate setting of the > BIOS setup). In other cases, when this BIOS feature is not > present, the possibility to start the watchdog immediately > after the module loading can be very useful. > > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> > --- > drivers/watchdog/wdat_wdt.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/drivers/watchdog/wdat_wdt.c b/drivers/watchdog/wdat_wdt.c > index cec7917790e5..b990d0197d2e 100644 > --- a/drivers/watchdog/wdat_wdt.c > +++ b/drivers/watchdog/wdat_wdt.c > @@ -61,6 +61,12 @@ module_param(timeout, int, 0); > MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default=" > __MODULE_STRING(WDAT_DEFAULT_TIMEOUT) ")"); > > +#define START_DEFAULT 0 > +static int start_enabled = START_DEFAULT; > +module_param(start_enabled, int, 0); > +MODULE_PARM_DESC(start_enabled, "Watchdog is started on module insertion " > + "(default=" __MODULE_STRING(START_DEFAULT) ")"); > + > static int wdat_wdt_read(struct wdat_wdt *wdat, > const struct wdat_instruction *instr, u32 *value) > { > @@ -437,6 +443,8 @@ static int wdat_wdt_probe(struct platform_device *pdev) > } > > wdat_wdt_boot_status(wdat); > + if (start_enabled) > + wdat_wdt_start(&wdat->wdd); No objections to this if it is really needed. However, I think it is better start the watchdog after devm_watchdog_register_device() has been called so we have everything initialized. > wdat_wdt_set_running(wdat); > > ret = wdat_wdt_enable_reboot(wdat); > -- > 2.25.1
On 2/19/21 6:01 AM, Flavio Suligoi wrote: > Hi Mika, > >>> const struct wdat_instruction *instr, u32 *value) >>> { >>> @@ -437,6 +443,8 @@ static int wdat_wdt_probe(struct platform_device >> *pdev) >>> } >>> >>> wdat_wdt_boot_status(wdat); >>> + if (start_enabled) >>> + wdat_wdt_start(&wdat->wdd); >> >> No objections to this if it is really needed. However, I think it is >> better start the watchdog after devm_watchdog_register_device() has been >> called so we have everything initialized. > > Yes, it is needed. We need this feature to enable the watchdog > as soon as possible and this is essential for unmanned applications, > such as routers, water pumping stations, climate data collections, > etc. > FWIW, in your use case the watchdog should be enabled in the BIOS/ROMMON. > Right, ok for the correct positioning of the wdat_wdt_start function > at the end of the watchdog device initialization. Thanks! > No, it isn't, because it won't set WDOG_HW_RUNNING, and the watchdog core won't know that the watchdog is running. The watchdog has to be started before the call to wdat_wdt_set_running(). If that isn't possible with the current location of wdat_wdt_set_running(), then wdat_wdt_set_running() has to be moved accordingly. Either case, both have to be called before calling devm_watchdog_register_device(). Having said that, I'd prefer to have a module parameter in the watchdog core. We already have a number of similar module parameters in various drivers, all named differently, and I'd rather not have more. Guenter >> >>> wdat_wdt_set_running(wdat); >>> >>> ret = wdat_wdt_enable_reboot(wdat); >>> -- >>> 2.25.1 > > Regards, > Flavio >
Hi Guenter > >>> const struct wdat_instruction *instr, u32 *value) { @@ -437,6 > >>> +443,8 @@ static int wdat_wdt_probe(struct platform_device > >> *pdev) > >>> } > >>> > >>> wdat_wdt_boot_status(wdat); > >>> + if (start_enabled) > >>> + wdat_wdt_start(&wdat->wdd); > >> > >> No objections to this if it is really needed. However, I think it is > >> better start the watchdog after devm_watchdog_register_device() has > >> been called so we have everything initialized. > > > > Yes, it is needed. We need this feature to enable the watchdog as soon > > as possible and this is essential for unmanned applications, such as > > routers, water pumping stations, climate data collections, etc. > > > FWIW, in your use case the watchdog should be enabled in the > BIOS/ROMMON. Yes, you are right, with the new BIOS version for the new boards we'll implement this features, but for the old boards it is no more possible. > > > Right, ok for the correct positioning of the wdat_wdt_start function > > at the end of the watchdog device initialization. Thanks! > > > > No, it isn't, because it won't set WDOG_HW_RUNNING, and the watchdog > core won't know that the watchdog is running. Ok > The watchdog has to be started before the call to wdat_wdt_set_running(). > If that isn't possible with the current location of wdat_wdt_set_running(), > then > wdat_wdt_set_running() has to be moved accordingly. > Either case, both have to be called before calling > devm_watchdog_register_device(). Ok > > Having said that, I'd prefer to have a module parameter in the watchdog > core. We already have a number of similar module parameters in various > drivers, all named differently, and I'd rather not have more. Ok, I'll study how to introduce a this new parameter in the wdog core, so that it can be available for all watchdog drivers. Then we'll have to think what to do with the existent similar parameters. I think we have to keep them for compatibility reasons. > > Guenter > Regards, Flavio
On Mon, Feb 22, 2021 at 11:28:18AM +0000, Flavio Suligoi wrote: [ ... ] > > Having said that, I'd prefer to have a module parameter in the watchdog > > core. We already have a number of similar module parameters in various > > drivers, all named differently, and I'd rather not have more. > > Ok, I'll study how to introduce a this new parameter in the wdog core, > so that it can be available for all watchdog drivers. > Then we'll have to think what to do with the existent similar parameters. > I think we have to keep them for compatibility reasons. > Correct. Thanks, Guenter
diff --git a/drivers/watchdog/wdat_wdt.c b/drivers/watchdog/wdat_wdt.c index cec7917790e5..b990d0197d2e 100644 --- a/drivers/watchdog/wdat_wdt.c +++ b/drivers/watchdog/wdat_wdt.c @@ -61,6 +61,12 @@ module_param(timeout, int, 0); MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default=" __MODULE_STRING(WDAT_DEFAULT_TIMEOUT) ")"); +#define START_DEFAULT 0 +static int start_enabled = START_DEFAULT; +module_param(start_enabled, int, 0); +MODULE_PARM_DESC(start_enabled, "Watchdog is started on module insertion " + "(default=" __MODULE_STRING(START_DEFAULT) ")"); + static int wdat_wdt_read(struct wdat_wdt *wdat, const struct wdat_instruction *instr, u32 *value) { @@ -437,6 +443,8 @@ static int wdat_wdt_probe(struct platform_device *pdev) } wdat_wdt_boot_status(wdat); + if (start_enabled) + wdat_wdt_start(&wdat->wdd); wdat_wdt_set_running(wdat); ret = wdat_wdt_enable_reboot(wdat);
Add the parameter "start_enable" to start the watchdog directly on module insertion. In an embedded system, for some applications, the watchdog must be activated as soon as possible. In some embedded x86 boards the watchdog can be activated directly by the BIOS (with an appropriate setting of the BIOS setup). In other cases, when this BIOS feature is not present, the possibility to start the watchdog immediately after the module loading can be very useful. Signed-off-by: Flavio Suligoi <f.suligoi@asem.it> --- drivers/watchdog/wdat_wdt.c | 8 ++++++++ 1 file changed, 8 insertions(+)