linux-toradex.git/drivers/net, branch v2.6.27.8

rtl8187: Add USB ID for Belkin F5D7050 with RTL8187B chip

2008-12-05T18:55:22+00:00

commit eaca90dab6ab9853223029deffdd226f41b2028c upstream.

The Belkin F5D7050rev5000de (id 050d:705e) has the Realtek RTL8187B chip
and works with the 2.6.27 driver.

Signed-off-by: Larry Finger 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rtl8187: add device ID 0bda:8198

2008-12-05T18:55:22+00:00

commit 746db510395e32ff57b9f8582e520df6b3fac618 upstream.

Reported by zOOmER.gm@gmail.com to work here:

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

Signed-off-by: John W. Linville 
Cc: Zoomer 
Signed-off-by: Greg Kroah-Hartman

e1000e: Use device_set_wakeup_enable

2008-12-05T18:55:21+00:00

commit 6ff68026f4757d68461b7fbeca5c944e1f5f8b44 upstream.

Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
e1000_set_wol().  Accordingly, use device_can_wakeup() for checking
if wake-up is supported by the device.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

e1000: Use device_set_wakeup_enable

2008-12-05T18:55:21+00:00

commit de1264896c8012a261c1cba17e6a61199c276ad3 upstream.

Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
e1000_set_wol().  Accordingly, use device_can_wakeup() for checking
if wake-up is supported by the device.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

igb: Use device_set_wakeup_enable

2008-12-05T18:55:21+00:00

commit e1b86d8479f90aadee57a3d07d8e61c815c202d9 upstream.

Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
igb_set_wol().  Accordingly, use device_can_wakeup() for checking
if wake-up is supported by the device.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

axnet_cs / pcnet_cs: moving PCMCIA_DEVICE_PROD_ID for Netgear FA411

2008-12-05T18:55:15+00:00

commit 208fbec5bec1de4fce48aab41efde11ba25ab04c upstream.

Hi,

after noticing that my Netgear FA411 (PCMCIA-NIC) [1] stopped working with
the release of the 2.6.25 kernel (sidux-version), I checked the
respective driver sources and noticed that the pcnet_cs driver bailed
out with "use axnet_cs instead" for the Netgear FA411, but axnet_cs
doesn't claim this ID.

I compiled a kernel with the PCMCIA-ID for the netgear card moved to
axnet_cs from pcnet_cs which worked. I then contacted sidux-kernel
maintainer Stefan Lippers-Hollmann who turned the info into this patch
and integrated it into the kernel:



This works for me and AFAIK there were no reports of any breakage for
other devices on sidux-support.

This looks like a trivial patch, but since I have very limited
experience with kernel modifications  I might be woefully wrong there.
But if there are no side effects of this patch, is it possible to get it
into the official kernel?

I can provide more detailed information on the affected hardware if
necessary.

-cord

[1]
Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
        Configuration:  state: on
        Product Name:   NETGEAR FA411 Fast Ethernet
        Identification: manf_id: 0x0149 card_id: 0x0411
                        function: 6 (network)
                        prod_id(1): "NETGEAR" (0x9aa79dc3)
                        prod_id(2): "FA411" (0x40fad875)
                        prod_id(3): "Fast Ethernet" (0xb4be14e3)
                        prod_id(4): --- (---)

From: Stefan Lippers-Hollmann 
Date: Sat, 1 Nov 2008 23:53:04 +0000
Subject: PCMCIA: move PCMCIA ID for Netgear FA411 from pcnet_cs to axnet_cs:

Since kernel 2.6.25, commit 61da96be07ec860e260ca4af0199b9d48d000b80
(pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.),
pcnet_cs bails out with "use axnet_cs instead" for the Netgear FA411, but
axnet_cs doesn't claim this ID.

Socket 1 Device 0:      [axnet_cs]              (bus ID: 1.0)
        Configuration:  state: on
        Product Name:   NETGEAR FA411 Fast Ethernet
        Identification: manf_id: 0x0149 card_id: 0x0411
                        function: 6 (network)
                        prod_id(1): "NETGEAR" (0x9aa79dc3)
                        prod_id(2): "FA411" (0x40fad875)
                        prod_id(3): "Fast Ethernet" (0xb4be14e3)
                        prod_id(4): --- (---)

Signed-off-by: Stefan Lippers-Hollmann 
Signed-off-by: Cord Walter 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ath9k: correct expected max RX buffer size

2008-12-05T18:55:15+00:00

commit b4b6cda2298b0c9a0af902312184b775b8867c65 upstream

We should only tell the hardware its capable of DMA'ing
to us only what we asked dev_alloc_skb(). Prior to this
it is possible a large RX'd frame could have corrupted
DMA data but for us but we were saved only because we
were previously also pci_map_single()'ing the same large
value. The issue prior to this though was we were unmapping
a smaller amount which the prior DMA patch fixed.

Signed-off-by: Bennyam Malavazi 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

ath9k: Fix SW-IOMMU bounce buffer starvation

2008-12-05T18:55:15+00:00

commit ca0c7e5101fd4f37fed8e851709f08580b92fbb3 upstream.

This should fix the SW-IOMMU bounce buffer starvation
seen ok kernel.org bugzilla 11811:

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

Users on MacBook Pro 3.1/MacBook v2 would see something like:

DMA: Out of SW-IOMMU space for 4224 bytes at device 0000:0b:00.0

Unfortunately its only easy to trigger on MacBook Pro 3.1/MacBook v2
so far so its difficult to debug (even with swiotlb=force).

We were pci_unmap_single()'ing less bytes than what we called
for with pci_map_single() and as such we were starving
the swiotlb from its 64MB amount of bounce buffers. We remain
consistent and now always use sc->rxbufsize for RX. While at
it we update the beacon DMA maps as well to only use the data
portion of the skb, previous to this we were pci_map_single()'ing
more data for beaconing than what we tell the hardware it can use,
therefore pushing more iotlb abuse.

Still not sure why this is so easily triggerable on
MacBook Pro 3.1, it may be the hardware configuration
tends to use more memory > 3GB mark for DMA.

Signed-off-by: Maciej Zenczykowski 
Signed-off-by: Bennyam Malavazi 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Greg Kroah-Hartman

atl1e: fix broken multicast by removing unnecessary crc inversion

2008-12-05T18:55:09+00:00

commit 7ee0fddfe05f105d3346aa8774695e7130697836 upstream.

Inverting the crc after calling ether_crc_le() is unnecessary and breaks
multicast. Remove it.

Tested-by: David Madore 
Signed-off-by: Jay Cliburn 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

r8169: select MII in Kconfig

2008-11-20T22:54:48+00:00

commit b73724921d906d1642f9f6d054079c6b095903fe upstream.

drivers/built-in.o: In function `rtl8169_gset_xmii':
r8169.c:(.text+0x82259): undefined reference to `mii_ethtool_gset'

Signed-off-by: Hugh Dickins 
Acked-by: Francois Romieu 
Cc: Edward Hsu 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman