From: Jeff Garzik <jgarzik@pobox.com>
To: Roger Luethi <rl@hellgate.ch>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@digeo.com>
Subject: Re: [0/4][via-rhine] Improvements
Date: Sat, 15 Feb 2003 16:49:24 -0500 [thread overview]
Message-ID: <3E4EB5E4.9070508@pobox.com> (raw)
In-Reply-To: <20030215205302.GB4627@k3.hellgate.ch>
Roger Luethi wrote:
> On Sat, 15 Feb 2003 14:08:24 -0500, Jeff Garzik wrote:
>
>
>>Looks good, all patches applied to 2.5.
>
>
> Thx. Patch to bump the version number up attached.
applied to 2.4 and 2.5
>>Should these apply to 2.4, too?
>
>
> Yes. I'm trying to keep the drivers in both trees in sync.
noted
>>Just a general comment, the reset logic seems a bit too much like voodoo
>>magic ;-)
>
>
> Look at the rest of the driver and you will find the reset voodoo magic is
> a perfect fit. We'd be waving dead chickens if only tar could handle them.
> Actually, the reset logic is slightly better because for every line I have
> some reasoning and actual tests conducted. The underlying problem is that
> the Rhine is only loosely documented and various revisions differ in
> amazing ways from each other and from the documentation that supposedly
> describes them.
>
> I've named the magic register in the patch below, does that ease your
> voodoo pain?
I applied the patch, but I meant more that wait_for_reset seems
questionable. There is generally a PIO or MMIO write preceding
wait_for_reset function call, and then the function delays. If the PCI
write is posted, for example, which at least my own Via EPIA does, then
you cannot be guaranteed the timing of
write[bwl]()
udelay(5)
PCI writes must be flushed, by doing a read[bwl]().
So, obvious PCI posting bugs in the wait_for_reset may be the cause of
some of the randomness that appears in the field. (Note this applies to
all PCI writes in the driver...)
So, I said "voodoo magic" because it doesn't really seem like we know
what the exact handling is... and randomly placed udelay() calls are,
unfortunately, sometimes a sign of driver bugs instead of necessary
hardware delays.
> I've been considering for a while to document the driver somewhat better.
> Are documentation patches welcome, or do you just want to have official
> word from VIA that they agree with the reset code? And if I need a few
> lines to explain some voodoo magic, is the prefered way to put it into the
> source or would a freshly created Documentation/network/via-rhine.txt be
> (my first choice but the directory typically contains user rather than
> developer documentation) the better place?
I would prefer both user and developer docs go in
Documentation/networking/via-rhine.txt. It is easy enough to note
separate sections of the document...
>>It would be nice long-term to get an official answer from Via
>>about the proper reset sequence and time limits. [regardless, like I
>
>
> Heh. If I had a contact at VIA I'd have many and more important questions
> than the reset sequence that actually works now, unlike lots of other
> stuff. Yes, reliable information from within VIA -- official or not --
> would be a big help.
Let me wave some dead chickens of my own, and see what happens...
Jeff
next prev parent reply other threads:[~2003-02-15 21:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-15 11:17 [0/4][via-rhine] Improvements Roger Luethi
2003-02-15 11:18 ` [1/4][via-rhine][PATCH] Trivial changes; not affecting functionality Roger Luethi
2003-02-15 11:18 ` [2/4][via-rhine][PATCH] Fix broken Tx underrun handling Roger Luethi
2003-02-15 11:18 ` [3/4][via-rhine][PATCH] Various duplex related fixes Roger Luethi
2003-02-15 11:18 ` [4/4][via-rhine][PATCH] Reset function rewrite Roger Luethi
2003-02-15 19:08 ` [0/4][via-rhine] Improvements Jeff Garzik
2003-02-15 20:53 ` Roger Luethi
2003-02-15 21:49 ` Jeff Garzik [this message]
2003-02-15 22:52 ` Roger Luethi
2003-02-16 0:16 ` Linus Torvalds
2003-02-16 11:01 ` Roger Luethi
2003-02-17 18:44 ` Jeff Garzik
2003-02-15 21:40 ` Jeff Garzik
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=3E4EB5E4.9070508@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@digeo.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rl@hellgate.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox