[PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt

[Grant Likely]

On Mon, Aug 3, 2009 at 12:46 PM, Albrecht Dreß<albrecht.dress at arcor.de> wrote:
> Am 03.08.09 19:50 schrieb(en) Grant Likely:
>>
>> Just about all mpc5200 device trees have the fsl,has-wdt property on GPT0
>> even when it isn't used as a watchdog.
>
> Sorry, I do not understand...  The file
> Documentation/powerpc/dts-bindings/fsl/mpc5200.txt says
>
> <snip>
> On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the board
> 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".  If 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).  In
> 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 GPT
>> watchdog driver into the regular GPT driver so that we don't have two device
>> drivers trying to bind against the same device.
>
> I see the benefit of removing some duplicate code and of having gpio access
> in parallel with the wdt, but it wouldn't solve the general confusion above!
>  Will 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.

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