Commit graph

5 commits

Author SHA1 Message Date
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
Jörn Engel
6ab3d5624e Remove obsolete #include <linux/config.h>
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-30 19:25:36 +02:00
Jeff Garzik
f3b197ac26 [netdrvr] trim trailing whitespace: 8139*.c, epic100, forcedeth, tulip/* 2006-05-26 21:39:03 -04:00
David S. Miller
689be43945 [NET]: Remove gratuitous use of skb->tail in network drivers.
Many drivers use skb->tail unnecessarily.

In these situations, the code roughly looks like:

	dev = dev_alloc_skb(...);

	[optional] skb_reserve(skb, ...);

	... skb->tail ...

But even if the skb_reserve() happens, skb->data equals
skb->tail.  So it doesn't make any sense to use anything
other than skb->data in these cases.

Another case was the s2io.c driver directly mucking with
the skb->data and skb->tail pointers.  It really just wanted
to do an skb_reserve(), so that's what the code was changed
to do instead.

Another reason I'm making this change as it allows some SKB
cleanups I have planned simpler to merge.  In those cleanups,
skb->head, skb->tail, and skb->end pointers are removed, and
replaced with skb->head_room and skb->tail_room integers.

Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
2005-06-28 15:25:31 -07: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