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

rtl8187: Fix lockups due to concurrent access to config routine

2008-08-20T18:05:10+00:00

With the rtl8187 driver, the config routine is not protected against
access before a previous call has completed. When this happens, the
TX loopback that is needed to change channels may cause the chip to
be locked with a reset needed to restore communications. This patch
entered mainline as commit 7dcdd073bf78bb6958bbc12a1a47754a0f3c4721.

The problem was found by Herton Ronaldo Krzesinski ,
who also suggested this type of fix.

Signed-off-by: Larry Finger 
Acked-by: Herton Ronaldo Krzesinski 
Acked-by: Hin-Tak Leung 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

r8169: avoid thrashing PCI conf space above RTL_GIGA_MAC_VER_06

2008-08-20T18:05:08+00:00

commit 77332894c21165404496c56763d7df6c15c4bb09 upstream

The magic write to register 0x82 will often cause PCI config space on
my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop)
to be filled with ones during driver load, and thus breaking NIC
operation until reboot. If it does not happen on first driver load it
can easily be reproduced by unloading and loading the driver a few
times.

The magic write was added long ago by this commit:

Author: François Romieu 
Date:   Sat Jan 10 06:00:46 2004 -0500

     [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one():
     - phy capability settings allows lower or equal capability as suggested
       in Realtek's changes;
     - I/O voodoo;
     - no need to s/mdio_write/RTL8169_WRITE_GMII_REG/;
     - s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/;
     - rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication
       of code (yep, the u16 -> int conversions should work as expected);
     - variable renames and whitepace changes ignored.

As the 8168 wasn't supported by that version this patch simply removes
the bogus write from mac versions <= RTL_GIGA_MAC_VER_06.

[The change above makes sense for the 8101/8102 too -- Ueimor]

Signed-off-by: Marcus Sundberg 
Signed-off-by: Francois Romieu 
Cc: Karsten Keil 
Signed-off-by: Greg Kroah-Hartman

Ath5k: kill tasklets on shutdown

2008-08-06T16:03:25+00:00

commit 10488f8ad62be3b860bad74e60b4fe6ab87aece3 upstream

Don't forget to kill tasklets on stop to not panic if they
fire after freeing some structures.

Signed-off-by: Jiri Slaby 
Acked-by: Nick Kossifidis 
Cc: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

Ath5k: fix memory corruption

2008-08-06T16:03:24+00:00

commit 3a0f2c871849f23c1070965bf94dec3f9c0b479d upstream

When signal is noisy, hardware can use all RX buffers and since the last
entry in the list is self-linked, it overwrites the entry until we link
new buffers.

Ensure that we don't free this last one until we are 100% sure that it
is not used by the hardware anymore to not cause memory curruption as
can be seen below.

This is done by checking next buffer in the list. Even after that we
know that the hardware refetched the new link and proceeded further
(the next buffer is ready) we can finally free the overwritten buffer.

We discard it since the status in its descriptor is overwritten (OR-ed
by new status) too.

=============================================================================
BUG kmalloc-4096: Poison overwritten
-----------------------------------------------------------------------------

INFO: 0xffff810067419060-0xffff810067419667. First byte 0x8 instead of 0x6b
INFO: Allocated in dev_alloc_skb+0x18/0x30 age=1118 cpu=1 pid=0
INFO: Freed in skb_release_data+0x85/0xd0 age=1105 cpu=1 pid=3718
INFO: Slab 0xffffe200019d0600 objects=7 used=0 fp=0xffff810067419048 flags=0x40000000000020c3
INFO: Object 0xffff810067419048 @offset=4168 fp=0xffff81006741c120

Bytes b4 0xffff810067419038:  4f 0b 02 00 01 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a O.......ZZZZZZZZ
  Object 0xffff810067419048:  6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
  Object 0xffff810067419058:  6b 6b 6b 6b 6b 6b 6b 6b 08 42 30 00 00 0b 6b 80 kkkkkkkk.B0...k.
  Object 0xffff810067419068:  f0 5d 00 4f 62 08 a3 64 00 0c 42 16 52 e4 f0 5a 360].Ob.243d..B.R344360Z
  Object 0xffff810067419078:  68 81 00 00 7b a5 b4 be 7d 3b 8f 53 cd d5 de 12 h...{245264276};.S315325336.
  Object 0xffff810067419088:  96 10 0b 89 48 54 23 41 0f 4e 2d b9 37 c3 cb 29 ....HT#A.N-2717303313)
  Object 0xffff810067419098:  d1 e0 de 14 8a 57 2a cc 3b 44 0d 78 7a 19 12 15 321340336..W*314;D.xz...
  Object 0xffff8100674190a8:  a9 ec d4 35 a8 10 ec 8c 40 a7 06 0a 51 a7 48 bb 2513543245250.354.@247..Q247H273
  Object 0xffff8100674190b8:  3e cf a1 c7 38 60 63 3f 51 15 c7 20 eb ba 65 30 >ϡ3078`c?Q.307.353272e0
 Redzone 0xffff81006741a048:  bb bb bb bb bb bb bb bb                         273273273273273273273273
 Padding 0xffff81006741a088:  5a 5a 5a 5a 5a 5a 5a 5a                         ZZZZZZZZ
Pid: 3297, comm: ath5k_pci Not tainted 2.6.26-rc8-mm1_64 #427

Call Trace:
 [] print_trailer+0xf6/0x150
 [] check_bytes_and_report+0x125/0x180
 [] check_object+0xac/0x260
 [] __slab_alloc+0x368/0x6d0
 [] ? wireless_send_event+0x142/0x310
 [] ? __alloc_skb+0x44/0x150
 [] ? wireless_send_event+0x142/0x310
 [] __kmalloc_track_caller+0xc3/0xf0
 [] __alloc_skb+0x6e/0x150
[... stack snipped]

FIX kmalloc-4096: Restoring 0xffff810067419060-0xffff810067419667=0x6b

FIX kmalloc-4096: Marking all objects used

Signed-off-by: Jiri Slaby 
Acked-by: Nick Kossifidis 
Cc: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath5k: don't enable MSI, we cannot handle it yet

2008-08-01T19:43:13+00:00

commit 256b152b005e319f985f50f2a910a75ba0def74f upstream

MSI is a nice thing, but we cannot enable it without changing the
interrupt handler.  If we do it, we break MSI capable hardware,
specifically AR5006 chipset.

Signed-off-by: Pavel Roskin 
Acked-by: Nick Kossifidis 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

b43legacy: Release mutex in error handling code

2008-08-01T19:43:12+00:00

commit 4104863fb4a724723d1d5f3cba9d3c5084087e45 upstream

The mutex is released on a successful return, so it would seem that it
should be released on an error return as well.

The semantic patch finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// 
@@
expression l;
@@

mutex_lock(l);
.. when != mutex_unlock(l)
    when any
    when strict
(
if (...) { ... when != mutex_unlock(l)
+   mutex_unlock(l);
    return ...;
}
|
mutex_unlock(l);
)
// 

Signed-off-by: Julia Lawall 
Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ixgbe: remove device ID for unsupported device

2008-08-01T19:43:11+00:00

commit bb5d10ac8cc315d53306963001fe650d88a1cbb2 upstream

The ixgbe driver was untested with device ID 8086:10c8 but still advertises
support.  Currently if this device is present in the system when the driver
is loaded, the system will panic.
Remove this device ID until full support can be tested with available
hardware.  This patch is necessary for 2.6.24, 2.6.25 and 2.6.26

Signed-off-by: Jesse Brandeburg 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

myri10ge: do not use mgp->max_intr_slots before loading the firmware

2008-08-01T19:43:06+00:00

part of commit 0dcffac1a329be69bab0ac604bf7283737108e68 upstream
(the upstream multislice patch contains this fix within a large
 rework of the code since there is one rx_done ring per slice. The
 old allocating is replaced by a call to myri10ge_probe_slices())


Allocating the rx_done ring requires mgp->max_intr_slots to
be valid, which requires that we already loaded the firmware
we are going to use with this ring.
So move the allocating after myri10ge_load_firmware()
(but keep it before myri10ge_reset() which already needs the
 rx_done ring).

If fixedsa regression where loading the driver would not
appear to do anything. Regression introduced in 2.6.26-rc3 by
commit 014377a1df693ff30a9e8b69f0bbb0a38e601f75

Reported and patch tested by Lukas Hejtmanek at
http://lkml.org/lkml/2008/7/22/305
Reproduced and patch tested also by me.

Signed-off-by: Brice Goglin 
Signed-off-by: Greg Kroah-Hartman

myri10ge: do not forget to setup the single slice pointers

2008-08-01T19:43:06+00:00

part of commit 0dcffac1a329be69bab0ac604bf7283737108e68 upstream
(the upstream multislice patch contains the same fix within
 myri10ge_alloc_slices() which does this for every slice)

Even if we don't have multiple slices in myri10ge in 2.6.26,
we already use some multislice-aware routines that need the
slice state pointers to mgp and dev to be valid.

This patch fixes a regression where configuring the interface up
would oops in myri10ge_allocate_rings() when using ss->mgp
(and later when using ss->dev).

Oops reported and patch tested by Lukas Hejtmanek at
http://lkml.org/lkml/2008/7/23/101

Signed-off-by: Brice Goglin 
Signed-off-by: Greg Kroah-Hartman

hdlcdrv: Fix CRC calculation.

2008-08-01T19:42:58+00:00

[ Upstream commit ae6134bdf3197206fba95563d755d2fa50d90ddd ]

This is a trivial patch against the hdlcdrv module that fixes its CRC
calculation. The finished CRC was overwriting the first two bytes of
each packet rather than being appended to the end.

I've tested this with 2.6.8 and 2.6.10-rc1, but hdlcdrv hasn't changed
much recently so it should work with many other kernel versions.

Signed-off-by: Micah Dowty 
Acked-by: Thomas Sailer 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman