From: Scott Wood <scottwood@freescale.com>
To: Wolfgang Denk <wd@denx.de>
Cc: Guenter Roeck <linux@roeck-us.net>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Wim Van Sebroeck <wim@iguana.be>, <linuxppc-dev@lists.ozlabs.org>,
<linux-kernel@vger.kernel.org>, <linux-watchdog@vger.kernel.org>
Subject: Re: [PATCH] watchdog: mpc8xxx_wdt: MPC8xx is HW enabled
Date: Fri, 6 Dec 2013 13:35:08 -0600 [thread overview]
Message-ID: <1386358508.7375.133.camel@snotra.buserror.net> (raw)
In-Reply-To: <20131202061418.05A11380BFE@gemini.denx.de>
On Mon, 2013-12-02 at 07:14 +0100, Wolfgang Denk wrote:
> Dear Guenter,
>
> In message <529B9152.9090106@roeck-us.net> you wrote:
> > On 11/30/2013 07:45 AM, Christophe Leroy wrote:
> > > MPC8xx watchdog is enabled at startup by HW.
> > > If the bootloader disables it, it cannot be reenabled.
> >
> > Is that true for all variants of 8xx, especially for 823 ? I am a bit concerned
> > about breaking compatibility with some chips ... assuming there was a reason
> > for not setting this flag originally.
>
> This is correct, and applies for all variants of the MPC8xx, including
> the MPC823 / MPC823E. From the UM:
>
> "The software watchdog timer can be disabled or its timeout
> period can be changed in the SYPCR. Once the SYPCR is written,
> it cannot be written again until a system reset."
>
> Actually this is the only correct behaviour. Any watchdog that can be
> disabled by software is not worth it's name, and unsuitable for any
> kind of aplications where security / reliability are required.
An optional locked state is a good thing, but making that the only way
the watchdog can function can render the watchdog unusable in systems
that need to go into low power states (unless the low power state
supresses the watchdog). And then there's broken hybrid things like the
booke watchdog, where you can't disable the watchdog reset action once
configured, but you can change the timeout to be effectively infinite
(which we've used as a workaround when entering low power states).
-Scott
next prev parent reply other threads:[~2013-12-06 19:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-30 15:45 Christophe Leroy
2013-12-01 19:43 ` Guenter Roeck
2013-12-02 6:14 ` Wolfgang Denk
2013-12-06 19:35 ` Scott Wood [this message]
2013-12-02 16:04 ` Guenter Roeck
2014-02-24 19:51 ` Wim Van Sebroeck
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=1386358508.7375.133.camel@snotra.buserror.net \
--to=scottwood@freescale.com \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=wd@denx.de \
--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
Powered by JetHome