Donald, thanks for taking the time to respond to my email, and I am
sorry that it has taken me a week to respond to yours. I wanted to
try a few things with your National Semiconductor DP38815 driver
first. I have made only a little progress, but I figure I owe you a
reply already.
On Tue, 1 Aug 2000, Donald Becker wrote:
>On Mon, 31 Jul 2000, Adam J. Richter wrote:
[...]
>> I made a first pass at porting Donald's natsemi.c driver to
>> 2.4.0-test5, with its simpler PCI-specific mechanisms, but I don't have
>> it working yet.
>What board are you using? The FA-311?
I am using a Netgear/Bay Networks FA-312 rev. A1.
>> For example, I am told that the people at Wyse had to extend the reset
>> code, because it had relied on the BIOS to have done some things that were
>> not necessarily guaranteed to get done (I don't know the details). So,
>> it is important that this support be integrated into the version that
>> goes into the kernel.
>The pci-scan code handles activating the card from ACPI D3 state (typically
>caused by warm-booting from a Windows version that uses Wake-On-LAN),
>enabling the memory and I/O regions, and setting the bus-master bit.
>I'm guessing that the "teamF1" people didn't know the requirements.
I don't know ACPI other than having a vague understanding that
there is no ACPI BIOS on the hardware platform on which this driver
must work.
>> I am still investigating the origins of the dp83815.c driver [...]
>I did note the lines at the bottom of the file matched my usual set-up,
>especially in the earlier version (distributed by Netgear) which has the
>compile lines verbatim. Still, it appears that most of the driver source
>lines were rewritten.
Thanks. I have updated your section of the credits in the
2.4.0-test5 driver to indicate that it appears to be derived from
your code. (My current working copies of my attempts to port both
the Wyse/TeamF1 version and yours are in
ftp://ftp.yggdrasil.com/private/adam/ethernet/ if anybody is interested.)
>And I certainly wouldn't to take credit for the ugly macros or the calls to
> udelay(2000);
>in the driver;-> (Yes, it's *much* easier to write a driver if you assume
>that it's the only important code running on the machine.)
The only calls to udelay(2000) that I see are when the hardware
is being reset, a hopefully a rare event. However, I agree it would be
good to determine if those 2ms delays can be eliminated.
Anyhow, here is the current status of my relatively novice
attemps at porting these two drivers to the PCI-based facilities of
2.4.0-test5:
natsemi.c (Don's driver) - This driver used {read,write}{b,w,l}
to memory addresses that apparently mapped into IO ports, which the
2.4.0-testX kernels discourage strongly by printing a warning every
time it happens. (I guess this ability is going to be removed.)
Changing the code to use {in,out}{b,w,l} has not worked as far as I
can tell, even though the IO addresses appear to be correct, and I
have verified that porting the TeamF1 routine for reading the mac
address into this driver works (and in this style of this driver), so
the board is alive.
dp83815.c (Wyse/NatSemi/TeamF1 driver) - This driver works but
is buggy. Most notably, emacs takes longer and longer to save a file
when this is my ethernet driver, until the delays become intolerable
(presumably this probably operates through NFS). The driver used to
occasionally segfault at initialization, but I am pretty sure that was
due to my not null terminating the table of PCI ID's. That is fixed now.
My more recent efforts have been aimed at getting natsemi.c
working, but I think I am going to take a look at the other
TeamF1/Natsemi-based dp83815 drivers that John Halewood and Ian Nelson
sent me, and see if that exposes the problem in dp83815.c.
Anyhow, if anyone wants to take a look at this work in progress,
both drivers are in ftp://ftp.yggdrasil.com/private/ethernet/.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:14 EST