At least some versions of the via-velocity hardware only support
checksumming IPv4 frames in hardware. However, the driver is currently
setting the NETIF_F_HW_CSUM flag, which indicates support for more than
just IPv4. This results in errors when trying to use IPv6 over
via-velocity hardware.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
This patch removes almost all inclusions of linux/version.h. The 3
#defines are unused in most of the touched files.
A few drivers use the simple KERNEL_VERSION(a,b,c) macro, which is
unfortunatly in linux/version.h.
There are also lots of #ifdef for long obsolete kernels, this was not
touched. In a few places, the linux/version.h include was move to where
the LINUX_VERSION_CODE was used.
quilt vi `find * -type f -name "*.[ch]"|xargs grep -El '(UTS_RELEASE|LINUX_VERSION_CODE|KERNEL_VERSION|linux/version.h)'|grep -Ev '(/(boot|coda|drm)/|~$)'`
search pattern:
/UTS_RELEASE\|LINUX_VERSION_CODE\|KERNEL_VERSION\|linux\/\(utsname\|version\).h
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
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!
John W. Linville