linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: "Albrecht Dreß" <albrecht.dress@arcor.de>
Cc: Linux PPC Development <linuxppc-dev@ozlabs.org>, wim@iguana.be
Subject: Re: [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
Date: Tue, 4 Aug 2009 22:47:37 -0600	[thread overview]
Message-ID: <fa686aa40908042147l1a270a37s154fb752b1c3a1a6@mail.gmail.com> (raw)
In-Reply-To: <1249325206.3404.1@antares>

On Mon, Aug 3, 2009 at 12:46 PM, Albrecht Dre=DF<albrecht.dress@arcor.de> w=
rote:
> Am 03.08.09 19:50 schrieb(en) Grant Likely:
>>
>> Just about all mpc5200 device trees have the fsl,has-wdt property on GPT=
0
>> even when it isn't used as a watchdog.
>
> Sorry, I do not understand... =A0The file
> Documentation/powerpc/dts-bindings/fsl/mpc5200.txt says
>
> <snip>
> On the mpc5200 and 5200b, GPT0 has a watchdog timer function. =A0If the b=
oard
> design supports the internal wdt, then the device node for GPT0 should
> include the empty property 'fsl,has-wdt'.
> </snip>
>
> I interpreted this as "if you don't want to have the wdt function of gpt0=
,
> remove this property". =A0If this assumption is wrong, how is the kernel
> supposed to decide if a device shall be used as gpt or as wdt?

That just states whether or not the functionality is there.  In fact,
the device can be used as both a WDT and a GPIO pin at the same time.

The kernel should decide how to use it based on what userspace asks it
to do.  If the WDT interface is opened, then it should be used as a
WDT.  If the GPIO interface is opened, then it should be used as a
GPIO (and not disturb the WDT settings).  If the gpt timer API is
called (not yet merged), then it should be used as a timer; but only
if it hasn't already been set up as a WDT.

>
>> The boards using GPT0 as a GPIO or timer will be broken by this patch.
>
> A wdt is a security device which will (IMHO) either not be used as such, =
or
> it is a *must not* be used for something else on a particular board (you =
may
> even want u-boot to activate it, e.g. to detect a hanging boot process). =
=A0In
> both cases, a "tuned" device tree is needed.

There is no property in the current binding that provides that data to
the kernel.  It works for it to be implicit based on how userspace
accesses the device, but if you want added assurance to ensure that
nothing else can use the WDT then you can define a new property to
state that explicitly and inhibit other uses.  That way no older
boards remain broken regardless of how they currently use GPT0

In fact, it probably makes sense to have a property to describe a
timeout value to preload into the WDT at boot time, or respect a
watchdog value already initialized by firmware (so that even if
userspace fails to start the watchdog daemon, the system will still
get reset).

>> I know it is a lot more work, but the correct solution is to merge the G=
PT
>> watchdog driver into the regular GPT driver so that we don't have two de=
vice
>> drivers trying to bind against the same device.
>
> I see the benefit of removing some duplicate code and of having gpio acce=
ss
> in parallel with the wdt, but it wouldn't solve the general confusion abo=
ve!
> =A0Will look into that, though...

I took a look at the code this evening, and it actually shouldn't be
too difficult to rework.  Most of the work would be relocating the
functions in the wdt driver into the gpt driver and wiring it into the
GPT probe/remove functions.

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

      reply	other threads:[~2009-08-05  4:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-03 16:40 [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt Albrecht Dreß
2009-08-03 17:50 ` Grant Likely
2009-08-03 18:46   ` Albrecht Dreß
2009-08-05  4:47     ` Grant Likely [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=fa686aa40908042147l1a270a37s154fb752b1c3a1a6@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=albrecht.dress@arcor.de \
    --cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).