summaryrefslogtreecommitdiffstats
path: root/drivers/net/b44.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'master' of ↵David S. Miller2009-06-151-1/+1
|\ | | | | | | | | | | | | | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 Conflicts: Documentation/feature-removal-schedule.txt drivers/scsi/fcoe/fcoe.c net/core/drop_monitor.c net/core/net-traces.c
| * trivial: typo (en|dis|avail|remove)bale -> (en|dis|avail|remove)ableThadeu Lima de Souza Cascardo2009-06-121-1/+1
| | | | | | | | | | Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* | net: use netdev stats in b44, sundance, via-rhine and via-velocityEric Dumazet2009-05-271-1/+0
|/ | | | | | | | Use struct net_device_stats provided in struct net_device instead of private ones. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* b44: GFP_DMA skb should not escape from driverEric Dumazet2009-01-151-1/+1
| | | | | | | | | | | | | | | | | | | | b44 chip has some hardware limitations, that need GFP_DMA bounce buffers in some situations. In order to not deplete DMA zone, we should keep allocated GFP_DMA skb only for driver use. At rx time, we copy such skb to newly allocated skb, reusing existing copybreak infrastructure. On machines with low amount of memory, all skb meet the hardware limitation, so no copy is needed. We detect this situation using a new device flag, set to one if one GFP_DMA skb was ever allocated by b44_alloc_rx_skb(). Previously allocated skb, even outside from DMA zone will then be recycled, to have minimal impact on DMA zone use. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Tested-by: Ionut Leonte <ionut.leonte@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* [B44]: port to native ssb supportMichael Buesch2007-10-101-74/+7
| | | | | Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* [NET]: Make NAPI polling independent of struct net_device objects.Stephen Hemminger2007-10-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several devices have multiple independant RX queues per net device, and some have a single interrupt doorbell for several queues. In either case, it's easier to support layouts like that if the structure representing the poll is independant from the net device itself. The signature of the ->poll() call back goes from: int foo_poll(struct net_device *dev, int *budget) to int foo_poll(struct napi_struct *napi, int budget) The caller is returned the number of RX packets processed (or the number of "NAPI credits" consumed if you want to get abstract). The callee no longer messes around bumping dev->quota, *budget, etc. because that is all handled in the caller upon return. The napi_struct is to be embedded in the device driver private data structures. Furthermore, it is the driver's responsibility to disable all NAPI instances in it's ->stop() device close handler. Since the napi_struct is privatized into the driver's private data structures, only the driver knows how to get at all of the napi_struct instances it may have per-device. With lots of help and suggestions from Rusty Russell, Roland Dreier, Michael Chan, Jeff Garzik, and Jamal Hadi Salim. Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra, Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan. [ Ported to current tree and all drivers converted. Integrated Stephen's follow-on kerneldoc additions, and restored poll_list handling to the old style to fix mutual exclusion issues. -DaveM ] Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* b44: packet offset is constantStephen Hemminger2007-07-081-2/+0
| | | | | | | The receive buffer offset is constant in this driver. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* b44 endian annotationsAl Viro2007-02-061-5/+5
| | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* [PATCH] b44: add wol for old nicGary Zambrano2006-06-221-0/+3
| | | | | | | | This patch adds wol support for the older 440x nics that use pattern matching. This patch is a redo thanks to feedback from Michael Chan and Francois Romieu. Signed-off-by: Gary Zambrano <zambrano@broadcom.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* [PATCH] b44: add wolGary Zambrano2006-06-221-0/+4
| | | | | | | | | Adds wol to the driver. This is a redo of a previous patch thanks to feedback from Francois Romieu. Signed-off-by Gary Zambrano <zambrano@broadcom.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* [PATCH] b44: replace B44_FLAG_INIT_COMPLETE with netif_running()Francois Romieu2005-11-091-1/+0
| | | | | Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
* [PATCH] b44: expose counters through ethtoolFrancois Romieu2005-11-071-20/+54
| | | | | Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
* [PATCH] b44: alternate allocation option for DMA descriptorsJohn W. Linville2005-10-181-0/+2
| | | | | | | | | | | | | | | | | This is a (final?) hack to support the odd DMA allocation requirements of the b44 hardware. The b44 hardware has a 30-bit DMA mask. On x86, anything less than a 32-bit DMA mask forces allocations into the 16MB GFP_DMA range. The memory there is somewhat limited, often resulting in an inability to initialize the b44 driver. This hack uses streaming DMA allocation APIs in order to provide an alternative in case the GFP_DMA allocation fails. It is somewhat ugly, but not much worse than the similar existing hacks to support SKB allocations in the same driver. FWIW, I have received positive feedback on this from several Fedora users. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+427
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!