Commit Graph

63 Commits (dde4e47e8fe333a5649a3fa0e7db1fa7c08d6158)

Author SHA1 Message Date
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
Francois Romieu 874a6214bc [PATCH] b44: miscellaneous cleanup
- remove unneeded forward declarations
- s/kmalloc + memset/kzalloc/
- whitespace readjustement can't hurt
- wrong comment: b44_init_rings _is_ called with a spinlock held in
  b44_{open/set_ringparam/set_pauseparam/etc}.
  Actually, it does not need to be able to sleep
- b44_remove_one() can not be issued with a NULL device in its
  private member: remove the test.

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
Francois Romieu c719369350 [PATCH] b44: b44_start_xmit returns with a lock held when it fails allocating
The patch simply factors out the release of the lock.

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
Pavel Machek 46e1785358 [PATCH] b44: fix suspend/resume
Fix suspend/resume on b44 by freeing/reacquiring irq.  Otherwise it hangs
on resume.

Signed-off-by: Pavel Machek <pavel@suse.cz>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-10-28 19:06:43 -04:00
Jesper Juhl b4558ea93d drivers/net: Remove pointless checks for NULL prior to calling kfree() 2005-10-28 16:53:13 -04:00
Andrew Morton 89358f90ab [netdrvr b44] include linux/dma-mapping.h to eliminate warning 2005-10-28 16:38:02 -04:00
Matthew Wilcox adf6e00064 [PATCH] b44 reports wrong advertised flags
Looks like someone used the MII constants instead of the ethtool constants.

Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-10-28 16:14:10 -04: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
John W. Linville 2160de53cc [PATCH] b44: support ETHTOOL_GPERMADDR
Add support for ETHTOOL_GPERMADDR to b44.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-09-14 08:29:31 -04:00
Len Brown 5028770a42 [ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc...
Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-12 17:21:56 -04:00
David Shaohua Li d58da59045 [ACPI] S3 Suspend to RAM: fix driver suspend/resume methods
Drivers should do this:

.suspend()
	pci_disable_device()

.resume()
	pci_enable_device()

http://bugzilla.kernel.org/show_bug.cgi?id=3469

Signed-off-by: David Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2005-07-11 23:23:46 -04:00
John W. Linville e254e9bff5 [PATCH] b44: check link state during open
Check the link state during b44_open.  This closes a 1 HZ window
that existed after b44_open ran but before the b44_timer handler ran,
during which ethtool would report "Link detected: yes" no matter what
the link state actually was.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
2005-06-27 00:46:40 -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