linux-mips
[Top] [All Lists]

Re: [PATCH] Add support for SB1 hardware watchdog.

To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] Add support for SB1 hardware watchdog.
From: Andrew Sharp <andy.sharp@onstor.com>
Date: Mon, 3 Dec 2007 11:24:18 -0800
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>, akpm@linux-foundation.org, wim@iguana.be
In-reply-to: <20071203183419.3213d551@the-village.bc.nu>
Organization: Onstor
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20071203181658.GA26631@onstor.com> <20071203183419.3213d551@the-village.bc.nu>
Sender: linux-mips-bounce@linux-mips.org
On Mon, 3 Dec 2007 18:34:19 +0000 Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote:

> > +     on such processors; this driver supports only the first
> > one,
> > +     because currently Linux only supports exporting one
> > watchdog
> > +     to userspace.
> 
> Yep. Perhaps that should change.

I thought about that just a little; I'm just not sure what it would
mean to have multiple watchdog devices.

> > + * wdog is the iomem address of the cfg register
> > + */
> > + void
> > +sbwdog_set(char __iomem *wdog, unsigned long t)
> > +{
> > +   __raw_writeb(0, wdog - 0x10);
> > +   __raw_writeq(t & 0x7fffffUL, wdog);
> > +}
> 
> What guarantees you don't get a pair of these calls at once or
> interleaving ?

Not much, I suppose, except that opening the device file is exclusive.
A thread could fork (or dup) after that and get crazy in a theoretical
scenario ... are you suggesting this be serialized?

> 
> 
> > +            * return the bits from the config register
> > +            */
> > +           ret = put_user(__raw_readb(user_dog), p);
> 
> Should return the translated status bits ?

Don't need this really.  I see a few more things that need cleaning
up so I will do that and submit another patch.  And with changing of
the directory up a level, I also forgot the makefile change.

> 
> 
> Alan

<Prev in Thread] Current Thread [Next in Thread>