From: Roger Luethi <rl@hellgate.ch>
To: Jeff Garzik <jgarzik@pobox.com>,
Linus Torvalds <torvalds@transmeta.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@digeo.com>,
Rogier Wolff <R.E.Wolff@BitWizard.nl>
Subject: [1/2][via-rhine][PATCH] reset logic
Date: Thu, 27 Feb 2003 12:45:04 +0100 [thread overview]
Message-ID: <20030227114504.GA4087@k3.hellgate.ch> (raw)
In-Reply-To: <20030227114417.GA3970@k3.hellgate.ch>
[-- Attachment #1: Type: text/plain, Size: 310 bytes --]
Since Linus and Jeff raised the issue of PCI posted writes, I cleaned up
wait_for_reset() some more. Experiments show that with MMIO, a reset may
indeed take seemingly longer -- that is fixed by flushing that buffer.
Also, the driver now polls the appropriate register while waiting for the
reset to finish.
[-- Attachment #2: via-rhine-1.17rc-01_reset.diff --]
[-- Type: text/plain, Size: 1404 bytes --]
--- 06_2.5.62/drivers/net/via-rhine.c Thu Feb 20 18:20:56 2003
+++ 07_reset/drivers/net/via-rhine.c Sat Feb 22 01:18:26 2003
@@ -368,6 +368,8 @@ enum chip_capability_flags {
#else
#define RHINE_IOTYPE (PCI_USES_IO | PCI_USES_MASTER | PCI_ADDR0)
#endif
+/* Beware of PCI posted writes */
+#define IOSYNC do { readb(dev->base_addr + StationAddr); } while (0)
/* directly indexed by enum via_rhine_chips, above */
static struct via_rhine_chip_info via_rhine_chip_info[] __devinitdata =
@@ -530,11 +532,12 @@ static int via_rhine_close(struct net_d
static void wait_for_reset(struct net_device *dev, int chip_id, char *name)
{
long ioaddr = dev->base_addr;
+ int boguscnt = 20;
- udelay(5);
+ IOSYNC;
if (readw(ioaddr + ChipCmd) & CmdReset) {
- printk(KERN_INFO "%s: Reset did not complete in 5 us. "
+ printk(KERN_INFO "%s: Reset not complete yet. "
"Trying harder.\n", name);
/* Rhine-II needs to be forced sometimes */
@@ -543,12 +546,14 @@ static void wait_for_reset(struct net_de
/* VT86C100A may need long delay after reset (dlink) */
/* Seen on Rhine-II as well (rl) */
- udelay(100);
+ while ((readw(ioaddr + ChipCmd) & CmdReset) && --boguscnt);
+ udelay(5);
+
}
if (debug > 1)
printk(KERN_INFO "%s: Reset %s.\n", name,
- (readw(ioaddr + ChipCmd) & CmdReset) ? "failed" : "succeeded");
+ boguscnt ? "succeeded" : "failed");
}
#ifdef USE_MEM
next prev parent reply other threads:[~2003-02-27 11:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-27 11:44 [0/2][via-rhine][ANNOUNCE] 1.17rc Roger Luethi
2003-02-27 11:45 ` Roger Luethi [this message]
2003-02-27 11:45 ` [2/2][via-rhine][PATCH] fix races Roger Luethi
2003-02-27 12:35 ` [3/2][via-rhine][PATCH] fixing the reset fix Roger Luethi
2003-03-01 12:15 ` [via-rhine][PATCH] 1.17 release Roger Luethi
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=20030227114504.GA4087@k3.hellgate.ch \
--to=rl@hellgate.ch \
--cc=R.E.Wolff@BitWizard.nl \
--cc=akpm@digeo.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.