Re: Ethernet driver for NatSemi dp83815

From: Donald Becker (becker@scyld.com)
Date: Tue Aug 01 2000 - 00:34:58 EST


On Mon, 31 Jul 2000, Adam J. Richter wrote:

> From a conversation that I had today, I now I believe that we all
> are using drivers that originated with TeamF1's work for National
> Semiconductor (today is the first time I had heard of them). I guess
> Don's driver was a separate effort.

Background: I wrote "natsemi.c" in early May 1999, using a datasheet
spirited out of NatSemi. They were supposed to be ready to release a
working chip to production in June '99, but later refused to say anything
about the schedule. Given that the current chip is rev. C, I'm guessing
that things went badly.

> 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?

> 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 am still investigating the origins of the dp83815.c driver,
> although the question may be academic, since the 2.4.0-test5 driver
> that I had already posted added author credits and GPL for Don
> Becker and Paul Gortmaker becuase I used ne2k-pci.c code to update
> the driver. If somebody did plaguize the code I suspect that someone

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.

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.)

> unfamiliar with free software mores thought that their employer had
> bought all the rights or executed the appropriate contracts to be able
> to remove the copyright notices, which is more the norm in the
> proprietary world.

The norm for the proprietary world is "steal the code and hope no one
ever sees the code". LynxOS and QNX have done it directly, as have
third-party VxWorks drivers.

Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf Clusters / Linux Installations
Annapolis MD 21403

-
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 : Mon Aug 07 2000 - 21:00:05 EST