summaryrefslogtreecommitdiff
path: root/drivers/net/netxen/netxen_nic_ethtool.c
diff options
context:
space:
mode:
authorScott Feldman <sfeldma@pobox.com>2005-11-09 02:18:52 -0500
committerJeff Garzik <jeff@garzik.org>2007-04-28 11:01:05 -0400
commitd52df4a35af569071fda3f4eb08e47cc7023f094 (patch)
treeb18fbd4ad63f3e19995d4b19017a44a02df9b707 /drivers/net/netxen/netxen_nic_ethtool.c
parent2933d42cb7b0f14e0f83f6f231c966e97c79cdc9 (diff)
downloadlinux-next-d52df4a35af569071fda3f4eb08e47cc7023f094.tar.gz
[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. (cherry picked from 29e79da9495261119e3b2e4e7c72507348e75976 commit)
Diffstat (limited to 'drivers/net/netxen/netxen_nic_ethtool.c')
0 files changed, 0 insertions, 0 deletions