Re: tulip driver in 2.1.11* - 2.1.21 is broken - new driver

B. James Phillippe (bryan@terran.org)
Fri, 18 Sep 1998 17:32:55 -0700 (PDT)


On Fri, 18 Sep 1998, Linus Torvalds wrote:

> On Fri, 18 Sep 1998 kuznet@ms2.inr.ac.ru wrote:
> >
> > "tbusy" was never used as lock (at least in tulip.c)
> > Transmitter is locked by bh_atomic in normal mode,
> > and by tx_semaphore in fastroute mode.
>
> Btw, can we get rid of all the "dev->tbusy" and "dev->interrupt" flags,
> and just use a regular spinlock or something around each driver?
>
> dev->tbusy has always been a bug, with no redeeming features. It's really
> only a way to say "yes, I have a bug, and I want to know about it" instead
> of fixing the problem properly.

Hello all,

I'm sorry, my head is starting to spin! I'm a novice kernel hacker
trying to break into ethernet device drivers. I've been working
steadfastly for the last couple of weeks on a DEC 21143 (only) driver.
Donald has been an invaluable resource to me; he has answered many
questions for me directly, and I have been using his pci-skeleton.c and
tulip.c, as well as David Davies' de4x5.c as examples. At this point, I
understand both drivers quite well and am making excellent progress on my
own driver.
But due to all of the recent discussion about the apparent
mishandlings of the tulip.c driver for transmitting and (possibly) plain
interrupt handling, I'm not sure what to do. Clearly I do not want to code
the same problems into my driver, but I'm not very understanding of what
exactly these problems are and how to avoid them.
If anyone could be so kind as to either briefly summarize these
issues for me in a private email or alternately point me at a driver
everyone agrees is a better example, I would be very greatful.
BTW, I do not intend to make my driver generic enough to use as a
general tulip driver (eg. for kernel inclusion). I only intend it to
support 21143 chips with non-MII PHY. I'm coding this for a specific
controller combo we use in our product, and as an educational experience.
If will of course be GPL. :)

thanks,
-bp

--
B. James Phillippe <bryan@terran.org>
Linux Software Engineer, WGTI.
http://earth.terran.org/~bryan

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