devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	devicetree@vger.kernel.org, linux-watchdog@vger.kernel.org,
	kernel@pengutronix.de
Subject: Re: [RFC] Using a watchdog as system reset
Date: Tue, 6 Oct 2020 20:41:30 +0200	[thread overview]
Message-ID: <20201006184130.r2lajves5l7lm2qk@pengutronix.de> (raw)
In-Reply-To: <41b0dfcd-adf1-296f-e5be-4db3eac9f097@roeck-us.net>

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

Hello Guenter,

On Tue, Oct 06, 2020 at 07:29:11AM -0700, Guenter Roeck wrote:
> On 10/6/20 4:56 AM, Guenter Roeck wrote:
> > On 10/6/20 3:29 AM, Uwe Kleine-König wrote:
> >> Hello,
> >>
> >> I have an i.MX25 system here with an external watchdog (using the
> >> gpio_wdt driver). So the internal watchdog (imx2_wdt) is unused.
> >>
> >> The problem with the unused imx2_wdt is that this usually provides the
> >> restart handler and now a reboot ends with
> >>
> >> 	reboot: Restarting system
> >> 	Reboot failed -- System halted
> >>
> >> until eventually the watchdog bites and resets the machine.
> >>
> >> I imagine that this is a common enough issue to warrant a generic
> >> solution. My suggestion is to formalize and implement something like:
> >>
> >> 	watchdog {
> >> 		compatible = "linux,wdt-gpio";
> >> 		...
> >> 		provide-system-reset;
> >> 	}
> >>
> >> with the sematic of: "This is the dedicated mechanism to reset this
> >> machine."
> >>
> > 
> > Some systems have more than one means to reset it, which is why
> > restart handlers have a priority. This in turn suggests that we should
> > maybe have a means to set that priority dynamically for the imx2_wdt driver
> > (or for watchdog drivers in general) instead of having it fixed at 128.
> > That would also solve your problem, assuming there is a different
> > (currently lower priority) means to reset the hardware in your system.
> > 
> > Alternatively, can't you just blacklist the imx2-wdt driver ?
> 
> After having another couple hours of sleep and a coffee, I wonder if
> this is already done, and the reboot just fails _because_ the imx2_wdt
> is _not_ loaded. Is that the case ?

Right, I disabled the imx2_wdt driver.
 
> If so, it looks like you want the reset functionality of the imx_wdt driver
> but not its watchdog functionality.

My thought was to use the gpio-watchdog as reset source, but using the
imx-watchdog only for reset but not watchdog is an obvious alternative I
didn't think about.

So I either want to make the gpio-watchdog provide a restart handler or
use the imx-watchdog driver to only provide a restart handler (but no
watchdog functionality).

> And the above would be a suggestion to add a "generic" restart
> functionality into the watchdog subsystem, one that uses a watchdog
> with minimum timeout to reset the system, even if its driver doesn't
> explicitly register a restart handler.  Is that what you are trying to
> suggest ?

Yes, every watchdog could provide a restart handler with just using the
watchdog callbacks.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

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

  reply	other threads:[~2020-10-06 18:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-06 10:29 [RFC] Using a watchdog as system reset Uwe Kleine-König
2020-10-06 11:56 ` Guenter Roeck
2020-10-06 14:29   ` Guenter Roeck
2020-10-06 18:41     ` Uwe Kleine-König [this message]
2020-10-06 21:04       ` Guenter Roeck
2020-10-07  7:12         ` Uwe Kleine-König
2020-10-07  7:25           ` Ahmad Fatoum
2020-10-07  7:32             ` Ahmad Fatoum
2020-10-07 10:18             ` dt-binding to define default watchdog and machine reset (Was: Re: [RFC] Using a watchdog as system reset) Uwe Kleine-König
2020-10-07 11:04               ` Guenter Roeck
2020-10-07 11:35                 ` Ahmad Fatoum

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=20201006184130.r2lajves5l7lm2qk@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@kernel.org \
    --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).