Commit graph

7 commits

Author SHA1 Message Date
Wang Chen
8f15ea42b6 netdevice: safe convert to netdev_priv() #part-3
We have some reasons to kill netdev->priv:
1. netdev->priv is equal to netdev_priv().
2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
   netdev_priv() is more flexible than netdev->priv.
But we cann't kill netdev->priv, because so many drivers reference to it
directly.

This patch is a safe convert for netdev->priv to netdev_priv(netdev).
Since all of the netdev->priv is only for read.
But it is too big to be sent in one mail.
I split it to 4 parts and make every part smaller than 100,000 bytes,
which is max size allowed by vger.

Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-11-12 23:38:36 -08:00
Grant Grundler
78a6551814 drivers/net/tulip: update first comment in tulip files
Three basic changes to the comments at the top of each file:
1) remove stale "Maintained by" line...I prefer people look in MAINTAINERS.
2) Drop reference to stale sf.net/tulip website (I didn't see anything
   of value there)
3) Point people at bugzilla.kernel.org to submit bugs...will always
   get tracked regardless of who the maintainer is.

Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Acked-by-stale-maintainer: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-06-24 22:59:26 -04:00
Grant Grundler
209261c019 [netdrvr] tulip_read_eeprom fixes for BUG 4420
If "location" is > "addr_len" bits, the high bits of location would interfere
with the READ_CMD sent to the eeprom controller.

A patch was submitted to bug:
    http://bugzilla.kernel.org/show_bug.cgi?id=4420

which simply truncated the "location", read whatever was in "location
modulo addr_len", and returned that value. That avoids confusing the
eeprom but seems like the wrong solution to me.

Correct would be to not read beyond "1 << addr_len" address of the eeprom.
I am submitting two changes to implement this:
1) tulip_read_eeprom will return zero (since we can't return -EINVAL)
   if this is attempted (defensive programming).
2) In tulip_core.c, fix the tulip_read_eeprom caller so they don't
   iterate past addr_len bits and make sure the entire tp->eeprom[]
   array is cleared.

I konw we don't strictly need both. I would prefer both in the tree
since it documents the issue and provides a second "defense" from
the bug from creeping back in.

Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2008-03-28 21:52:14 -04:00
Valerie Henson
6b92801b43 [PATCH] Change tulip maintainer
Signed-off-by: Valerie Henson <val_henson@linux.intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

 MAINTAINERS                    |    4 ++--
 drivers/net/tulip/21142.c      |    2 +-
 drivers/net/tulip/eeprom.c     |    2 +-
 drivers/net/tulip/interrupt.c  |    2 +-
 drivers/net/tulip/media.c      |    2 +-
 drivers/net/tulip/pnic.c       |    2 +-
 drivers/net/tulip/pnic2.c      |    2 +-
 drivers/net/tulip/timer.c      |    2 +-
 drivers/net/tulip/tulip_core.c |    2 +-
 9 files changed, 10 insertions(+), 10 deletions(-)
2006-09-11 09:05:37 -04:00
Jeff Garzik
f3b197ac26 [netdrvr] trim trailing whitespace: 8139*.c, epic100, forcedeth, tulip/* 2006-05-26 21:39:03 -04:00
Ralf Baechle
12755c16a9 Tulip fixes for Cobalt Qube/RaQ 2005-06-26 17:45:52 -04:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00