One of the last steps necessary to deprecate the eepro100 driver is to
ensure that e100 works everywhere that eepro100 does.
The eepro100 removal has been blocked for almost a year by a vague
suggestion from Russell that e100 doesn't work on ARM. But he doesn't
have that machine anymore. So, we're stuck in limbo.
This is a call to anyone who can test an Intel 10/100 chip on the ARM
platform, in an effort to see where we are. I'm looking for answers to
the following two questions:
1) Does e100 driver work on ARM?
2) If not, does the "e100-sbit" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
work on ARM?
FWIW, the e100-sbit branch has been in Andrew Morton's -mm tree since
Nov 2005.
Below is the commit message for the e100-sbit change, in case anyone is
interested. I'm also hoping that Intel will help solve this problem,
but poking Intel hasn't produced very much :(
Jeff
commit 32c1459bb3814274b3c5e0c5ed4efc6c0aa89eb4
Author: Scott Feldman <[email protected]>
Date: Wed Nov 9 02:18:52 2005 -0500
[netdrvr e100] experiment with doing RX in a similar manner to eepro100
I was going to say that eepro100's speedo_rx_link() does the same DMA
abuse as e100, but then I noticed one little detail: eepro100 sets both
EL (end of list) and S (suspend) bits in the RFD as it chains it to the
RFD list. e100 was only setting the EL bit. Hmmm, that's interesting.
That means that if HW reads a RFD with the S-bit set, it'll process
that RFD and then suspend the receive unit. The receive unit will
resume when SW clears the S-bit. There is no need for SW to restart
the receive unit. Which means a lot of the receive unit state tracking
code in the driver goes away.
So here's a patch against 2.6.14. (Sorry for inlining it; the mailer
I'm using now will mess with the word wrap). I can't test this on
XScale (unless someone has an e100 module for Gumstix :) . It should
be doing exactly what eepro100 does with RFDs. I don't believe this
change will introduce a performance hit because the S-bit and EL-bit go
hand-in-hand meaning if we're going to suspend because of the S- bit,
we're on the last resource anyway, so we'll have to wait for SW to
replenish.
--
VGER BF report: U 0.499999
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
