From: Guenter Roeck <linux@roeck-us.net>
To: Flavio Suligoi <f.suligoi@asem.it>,
Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: R: [PATCH v1] watchdog: wdat: add param. to start wdog on module insertion
Date: Fri, 19 Feb 2021 07:32:59 -0800 [thread overview]
Message-ID: <4ed7ec8c-d5bf-41b8-96c4-b34db670315d@roeck-us.net> (raw)
In-Reply-To: <bf4e89bd11964f2e9f621f949adc338b@asem.it>
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
>
next prev parent reply other threads:[~2021-02-19 15:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 16:32 [PATCH v1] watchdog: wdat: add param. to start wdog on module insertion Flavio Suligoi
2021-02-19 10:54 ` Mika Westerberg
2021-02-19 14:01 ` R: " Flavio Suligoi
2021-02-19 15:32 ` Guenter Roeck [this message]
2021-02-22 11:28 ` Flavio Suligoi
2021-02-22 21:30 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ed7ec8c-d5bf-41b8-96c4-b34db670315d@roeck-us.net \
--to=linux@roeck-us.net \
--cc=f.suligoi@asem.it \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=wim@linux-watchdog.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).