Commit Graph

6 Commits

Author SHA1 Message Date
Gary Zambrano 725ad800b7 [PATCH] b44: add wol for old nic
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>
2006-06-22 23:16:13 -04:00
Gary Zambrano 52cafd9655 [PATCH] b44: add wol
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>
2006-06-22 23:16:13 -04:00
Francois Romieu b9dcbb40f4 [PATCH] b44: replace B44_FLAG_INIT_COMPLETE with netif_running()
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-09 01:02:41 -05:00
Francois Romieu 3353930d9d [PATCH] b44: expose counters through ethtool
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-11-07 03:37:05 -05:00
John W. Linville 9f38c636ab [PATCH] b44: alternate allocation option for DMA descriptors
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>
2005-10-18 22:27:13 -04: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