From: Thomas Koeller <thomas@koeller.dyndns.org>
To: Dave Jones <davej@redhat.com>
Cc: wim@iguana.be, linux-kernel@vger.kernel.org,
Ralf Baechle <ralf@linux-mips.org>,
linux-mips@linux-mips.org
Subject: Re: [PATCH] Added MIPS RM9K watchdog driver
Date: Sat, 12 Aug 2006 01:49:23 +0200 [thread overview]
Message-ID: <200608120149.23380.thomas@koeller.dyndns.org> (raw)
In-Reply-To: <20060811205639.GK26930@redhat.com>
On Friday 11 August 2006 22:56, Dave Jones wrote:
> On Thu, Aug 10, 2006 at 11:19:13PM +0200, thomas@koeller.dyndns.org wrote:
> > This is a driver for the on-chip watchdog device found on some
> > MIPS RM9000 processors.
> >
> > Signed-off-by: Thomas Koeller <thomas.koeller@baslerweb.com>
>
> Mostly same nit-picking comments as your other driver..
Which one?
>
> > +++ b/drivers/char/watchdog/rm9k_wdt.c
> > ...
> > +
> > +#include <linux/config.h>
>
> not needed.
It is, otherwise I do not get CONFIG_WATCHDOG_NOWAYOUT.
>
> > +/* Function prototypes */
> > +static int __init wdt_gpi_probe(struct device *);
> > +static int __exit wdt_gpi_remove(struct device *);
> > +static void wdt_gpi_set_timeout(unsigned int);
> > +static int wdt_gpi_open(struct inode *, struct file *);
> > +static int wdt_gpi_release(struct inode *, struct file *);
> > +static ssize_t wdt_gpi_write(struct file *, const char __user *,
> > size_t, loff_t *);
> > +static long wdt_gpi_ioctl(struct file *, unsigned int, unsigned long);
> > +static const struct resource *wdt_gpi_get_resource(struct
> > platform_device *, const char *, unsigned int);
> > +static int wdt_gpi_notify(struct notifier_block *, unsigned long, void
> > *); +static irqreturn_t wdt_gpi_irqhdl(int, void *, struct pt_regs *);
>
> Can probably (mostly?) go away with some creative reordering.
Probably, but should it? I always considered it good style to have
prototypes for all functions.
>
> > +static int locked = 0;
>
> unneeded initialisation.
Not strictly needed, that's true, but does not do any harm either
and expresses the intention clearly.
>
> > +static int nowayout =
> > +#if defined(CONFIG_WATCHDOG_NOWAYOUT)
> > + 1;
> > +#else
> > + 0;
> > +#endif
>
> static int nowayout = CONFIG_WATCHDOG_NOWAYOUT;
>
> should work.
Does not work. If the option is not selected, CONFIG_WATCHDOG_NOWAYOUT
is undefined, not zero.
>
> > +static void wdt_gpi_set_timeout(unsigned int to)
> > +{
> > + u32 reg;
> > + const u32 wdval = (to * CLOCK) & ~0x0000000f;
> > +
> > + lock_titan_regs();
> > + reg = titan_readl(CPCCR) & ~(0xf << (wd_ctr * 4));
> > + titan_writel(reg, CPCCR);
> > + wmb();
> > + __raw_writel(wdval, wd_regs + 0x0000);
> > + wmb();
> > + titan_writel(reg | (0x2 << (wd_ctr * 4)), CPCCR);
> > + wmb();
> > + titan_writel(reg | (0x5 << (wd_ctr * 4)), CPCCR);
> > + iob();
> > + unlock_titan_regs();
> > +}
>
> As in the previous driver, are these barriers strong enough?
> Or do they need explicit reads of the written addresses to flush the write?
I think they are. Remember, the entire device is integrated in the
processor. No external buses involved.
>
> Dave
Thanks for your comments!
Thomas
--
Thomas Koeller
thomas@koeller.dyndns.org
next prev parent reply other threads:[~2006-08-11 23:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-10 21:19 thomas
2006-08-11 20:07 ` Alan Cox
2006-08-12 16:06 ` Thomas Koeller
2006-08-12 22:41 ` Ralf Baechle
2006-08-12 17:45 ` Thomas Koeller
2006-08-12 20:43 ` Alan Cox
2006-08-11 20:56 ` Dave Jones
2006-08-11 23:49 ` Thomas Koeller [this message]
2006-08-11 22:06 ` Oleg Verych
2006-08-12 0:06 ` Dave Jones
2006-08-12 0:22 ` Ralf Baechle
2006-08-14 14:14 ` Joseph Fannin
2006-08-14 15:30 ` Sam Ravnborg
2006-08-14 16:21 ` Randy.Dunlap
2006-08-14 16:26 ` Dave Jones
2006-08-14 16:27 ` Roland Dreier
2006-08-14 15:50 ` Wim Van Sebroeck
2006-08-14 19:55 ` [PATCH] " Thomas Koeller
2006-08-14 17:25 ` [PATCH] Added " Luca
2006-11-01 18:46 Wim Van Sebroeck
2006-11-01 18:50 ` Ralf Baechle
2006-11-01 19:11 ` Wim Van Sebroeck
2006-11-01 20:43 ` Sam Ravnborg
2006-11-02 6:11 ` Randy Dunlap
2006-11-02 14:04 ` Ralf Baechle
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=200608120149.23380.thomas@koeller.dyndns.org \
--to=thomas@koeller.dyndns.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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
all inboxes | Powered by JetHome®