aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/tulip/eeprom.c
AgeCommit message (Collapse)Author
2008-11-12netdevice: safe convert to netdev_priv() #part-3Wang Chen
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-06-24drivers/net/tulip: update first comment in tulip filesGrant Grundler
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-03-28[netdrvr] tulip_read_eeprom fixes for BUG 4420Grant Grundler
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>
2006-09-11[PATCH] Change tulip maintainerValerie Henson
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-05-26[netdrvr] trim trailing whitespace: 8139*.c, epic100, forcedeth, tulip/*Jeff Garzik
2005-06-26Tulip fixes for Cobalt Qube/RaQRalf Baechle
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!