From: "Winkler, Tomas" <tomas.winkler@intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@iguana.be>,
"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Usyskin, Alexander" <alexander.usyskin@intel.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [watchdog] watchdog: mei_wdt: request stop on unregister
Date: Sat, 23 Jan 2021 21:39:29 +0000 [thread overview]
Message-ID: <a25386324dba4721a43bc7e4a3d0e5a5@intel.com> (raw)
In-Reply-To: <20210123184744.GA61339@roeck-us.net>
>
> Tomas,
>
> On Thu, Jan 07, 2021 at 04:12:15PM -0800, Guenter Roeck wrote:
> > Hi,
> >
> > On Thu, Jan 07, 2021 at 09:57:30PM +0200, Tomas Winkler wrote:
> > > From: Alexander Usyskin <alexander.usyskin@intel.com>
> > >
> > > Send the stop command to the firmware on watchdog unregister to
> > > eleminate false event on suspend.
> > >
> >
> > Normally the watchdog driver would not be expected to unregister
> > during suspend, only when the driver is manually unloaded.
> > To support suspend/resume, other watchdog drivers implement
> > suspend/resume functions to stop the watchdog on suspend and to
> > restart it on resume. Unloading a watchdog driver on suspend would
> > also have odd implications for userspace watchdog daemons.
> >
> > On top of that, it should not actually be possible to unregister a
> > watchdog while it is in use (because it is open in that case and
> > should be marked as busy). watchdog_stop_on_unregister() only serves
> > as backup in case someone actually manages to unload the driver while
> > the watchdog is running. The function was implemented to avoid calls
> > to stop the watchdog in the remove function because I can not
> > mathematically prove that there are no situations where the watchdog
> > is unloaded while running.
> > However, I have not actually been able to do that.
> >
> > Are you sure this patch is doing what you expect it to do ?
> >
>
> I have not heard anything back. I tried to understand how this patch would
> resolve a problem during suspend/resume, but I didn't find anything.
Sorry, I've already prepared better commit message, just had to move the attention to other issues.
>
> Can you maybe add a log message showing the false event that is prevented
> with this patch, and some context explaining how the patch fixes the
> problem ?
The MEI watchdog device lives on mei client bus and currently this bus has a special behavior, on suspend it destroys all the devices that are present on the bus.
This is due to fact that the context in the MEI firmware is also lost on suspend and the resume is always a fresh start.
Thanks
Tomas
>
> Thanks,
> Guenter
>
> > Thanks,
> > Guenter
> >
> > > Cc: <stable@vger.kernel.org>
> > > Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> > > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > > ---
> > > drivers/watchdog/mei_wdt.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> > > index 5391bf3e6b11..c5967d8b4256 100644
> > > --- a/drivers/watchdog/mei_wdt.c
> > > +++ b/drivers/watchdog/mei_wdt.c
> > > @@ -382,6 +382,7 @@ static int mei_wdt_register(struct mei_wdt *wdt)
> > >
> > > watchdog_set_drvdata(&wdt->wdd, wdt);
> > > watchdog_stop_on_reboot(&wdt->wdd);
> > > + watchdog_stop_on_unregister(&wdt->wdd);
> > >
> > > ret = watchdog_register_device(&wdt->wdd);
> > > if (ret)
> > > --
> > > 2.26.2
> > >
prev parent reply other threads:[~2021-01-23 21:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 19:57 [watchdog] watchdog: mei_wdt: request stop on unregister Tomas Winkler
2021-01-08 0:12 ` Guenter Roeck
2021-01-23 18:47 ` Guenter Roeck
2021-01-23 21:39 ` Winkler, Tomas [this message]
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=a25386324dba4721a43bc7e4a3d0e5a5@intel.com \
--to=tomas.winkler@intel.com \
--cc=alexander.usyskin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=stable@vger.kernel.org \
--cc=wim@iguana.be \
/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