All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Subject: Re: [RFC PATCH] watchdog: renesas_wdt: don't sleep in atomic context
Date: Sat, 19 Dec 2020 18:29:52 +0100	[thread overview]
Message-ID: <20201219172952.GA15530@kunai> (raw)
In-Reply-To: <20201002164722.GA46009@roeck-us.net>

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]


> > Convert usleep_range() to udelay() to avoid the bug. The downside is
> > busy looping when the watchdog is started or stopped (64us or 96us in my
> > case). However, this happens rarely enough, so it seems acceptable.
> > 
> > Fixes: b836005b4f95 ("watchdog: renesas_wdt: Add a few cycles delay")
> > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > ---
> > 
> > We could also add a new flag in the watchdog core "IS_RESTARTING" or
> > similar and check that in the driver. Depending on the flag, we use
> > udelay() or usleep_range(). Not sure, if this is feasible or
> > over-engineered, though. Looking forward for comments.
> 
> Seems to be neither to me. I don't know if there are many drivers who sleep
> in the stop function, but even if there are none (today) it would be a
> generic problem.
> 
> On a side note, I am quite sure there is a system wide flag indicating
> that the system is rebooting. Maybe we can just use that ?

So, it took me a while to get back to this. Yes, we can use system_state
to determine which udelay to use. I am working on a helper for that.
However, as it turned out, this driver needs a different approach
because there were multiple issues with reusing the generic wdt-start
routine. Proper patch will come in some minutes.

Thanks for your input!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2020-12-19 17:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 15:09 [RFC PATCH] watchdog: renesas_wdt: don't sleep in atomic context Wolfram Sang
2020-10-02 15:12 ` Wolfram Sang
2020-10-02 16:47 ` Guenter Roeck
2020-12-19 17:29   ` Wolfram Sang [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=20201219172952.GA15530@kunai \
    --to=wsa+renesas@sang-engineering.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.