aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/fealnx.c
Commit message (Collapse)AuthorAge
* [netdrvr] Remove long-unused bits from Becker template driversJeff Garzik2006-06-26
| | | | | | | | | | | | | | | | | | Symbols such as PCI_USES_IO, PCI_ADDR0, etc. originated from Donald Becker's net driver template, but have been long unused. Remove. In a few drivers, this allows the further eliminate of the pci_flags (or just plain flags) member in the template driver probe structure. Most of this logic is simply open-coded in most drivers, since it never changes. Made a few other cleanups while I was in there, too: * constify, __devinitdata several PCI ID tables * replace table terminating entries such as "{0,}," and "{NULL}," with a more-clean "{ }". Signed-off-by: Jeff Garzik <jeff@garzik.org>
* Massive net driver const-ification.Arjan van de Ven2006-03-03
|
* [NET]: Remove gratuitous use of skb->tail in network drivers.David S. Miller2005-06-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [PATCH] fealnx.c calls dev_kfree_skb from atomic contextDenis Vlasenko2005-06-26
| | | | Signed-off-by: Andrew Morton <akpm@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
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!