linux-toradex.git/drivers, branch v2.6.32.7

iwlwifi: Fix throughput stall issue in HT mode for 5000

2010-01-28T23:02:56+00:00

commit 1152dcc28c66a74b5b3f1a3ede0aa6729bfd48e4 upstream

Similar to 6000 and 1000 series, RTS/CTS is the recommended protection
mechanism for 5000 series in HT mode based on the HW design.

Using RTS/CTS will better protect the inner exchange from interference,
especially in highly-congested environment, it also prevent uCode encounter
TX FIFO underrun and other HT mode related performance issues.

Signed-off-by: Wey-Yi Guy 
Signed-off-by: Reinette Chatre 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ACPI: enable C2 and Turbo-mode on Nehalem notebooks on A/C

2010-01-28T23:02:54+00:00

upstream in 2.6.33-rc:  5d76b6f6c17572e662f5c99c2023adae92100855

Refreshed here for 2.6.32.y, applies w/ offset back to 2.6.29.y.

Linux has always ignored ACPI BIOS C2 with exit latency > 100 usec,
and the ACPI spec is clear that is correct FADT-supplied C2.

However, the ACPI spec explicitly states that _CST-supplied C-states
have no latency limits.

So move the 100usec C2 test out of the code shared
by FADT and _CST code-paths, and into the FADT-specific path.

This bug has not been visible until Nehalem, which advertises
a CPU-C2 worst case exit latency on servers of 205usec.
That (incorrect) figure is being used by BIOS writers
on mobile Nehalem systems for the AC configuration.
Thus, Linux ignores C2 leaving just C1, which is
saves less power, and also impacts performance
by preventing the use of turbo mode.

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

Tested-by: Alex Chiang 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

IPoIB: Clear ipoib_neigh.dgid in ipoib_neigh_alloc()

2010-01-28T23:02:51+00:00

commit 0cd4d0fd9b0a4e10c091fc6316d1bf92885dcd9c upstream.

IPoIB can miss a change in destination GID under some conditions.  The
problem is caused when ipoib_neigh->dgid contains a stale address.
The fix is to set ipoib_neigh->dgid to zero in ipoib_neigh_alloc().

This can happen when a system using bonding on its IPoIB interfaces
has switched its active interface from interface A to B and back to A.
The system that fails over will not correctly processes the 2nd
address change, as described below.

When an address has changed neighbor->ha is updated with the new
address.  Each neighbor has an associated ipoib_neigh.
ipoib_neigh->dgid also holds a copy of the remote node's hardware
address.  When an address changes neighbor->ha is updated by the
network layer (arp code) with the new address.  IPoIB detects this
change in ipoib_start_xmit() by comparing neighbor->ha with
ipoib_neigh->dgid.  The bug is that ipoib_neigh->dgid may already
contain the new address (A) thus the change from B to A is missed by
ipoib.  Here is the sequence of events:

    ipoib_neigh->dgid = A  and  neighbor->ha = A

The address is switched to B (the first switch)

    neighbor->ha = B

The change is seen in ipoib_start_xmit() -- neighbor->ha !=
ipoib_neigh->dgid so ipoib_neigh is released, and a new one is
allocated.

The allocator may return the same chunk of memory that was just
released, therefore ipoib_neigh->dgid still contains A at this point.

ipoib_neigh->dgid should be updated in neigh_add_path(), but if the
following conditions are true dgid is not updated:

        1) __path_find() returns a path
        2) path->ah is NULL

The remote system now switches from address B to A, neighbor->ha is
updated to A.

Now we have again : ipoib_neigh->dgid = A  and  neighbor->ha = A

Since the addresses are the same ipoib won't process the change in
address.  Fix this by zeroing out the dgid field when allocating a new
struct ipoib_neigh.

Signed-off-by: David Wilder 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

UBI: initialise update marker

2010-01-28T23:02:34+00:00

commit ff998793288b49a3b22d929bf8e56362320905ff upstream.

The in kernel copy of a volume's update marker is not initialised from the
volume table. This means that volumes where an update was unfinnished will
not be treated as "forbidden to use". This is basically that the update
functionality was broken.

Signed-off-by: Peter Horton 
Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman

UBI: fix memory leak in update path

2010-01-28T23:02:31+00:00

commit ebddd63b74dcf1cb676d14328d5852f1fee19a8a upstream.

When truncating an UBI volume, UBI should allocates a PEB-sized
buffer but does not release it, which leads to memory leaks.
This patch fixes the issue.

Reported-by: Marek Skuczynski 
Signed-off-by: Artem Bityutskiy 
Tested-by: Marek Skuczynski 
Signed-off-by: Greg Kroah-Hartman

hwmon: (fschmd) Fix a memleak on multiple opens of /dev/watchdog

2010-01-28T23:02:27+00:00

commit c453615f77aa51593c1c9c9031b4278797d3fd19 upstream.

When /dev/watchdog gets opened a second time we return -EBUSY, but
we already have got a kref then, so we end up leaking our data struct.

Signed-off-by: Hans de Goede 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

netiucv: displayed TX bytes value much too high

2010-01-28T23:02:24+00:00

commit 998221c26b86a7edd621e66b437628c5ec0f8e9b upstream.

tx_bytes value must be updated by skb length before skb is freed.

Signed-off-by: Ursula Braun 
Signed-off-by: David S. Miller 
Acked-by: John Jolly 
Signed-off-by: Greg Kroah-Hartman

cio: dont panic in non-fatal conditions

2010-01-28T23:02:22+00:00

commit 16b9a0571da4ee5cd15ca75e871722b0b5aee64d upstream.

Remove the call to BUG() for situations which are unexpected
but do not cause actual problems.

Signed-off-by: Peter Oberparleiter 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

cio: fix double free in case of probe failure

2010-01-28T23:02:20+00:00

commit 48e4c385c5f54626651cca027afe242439281899 upstream.

io_subchannel_probe() frees memory for sch->private which is later
freed again when io_subchannel_remove() is called. Fix this problem
by removing the cleanup in io_subchannel_probe().

Signed-off-by: Peter Oberparleiter 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

V4L/DVB (13826): uvcvideo: Fix controls blacklisting

2010-01-28T23:02:19+00:00

commit 385097e08b9c24655626ed760bc67eb7e50115a0 upstream.

The control blacklisting code erroneously used usb_match_id() by passing
a pointer to a usb_device_id structure instead of an array of such
structures.

Replace the usb_match_id() call by usb_match_id_one().

Thanks to Paulo Assis for diagnosing the bug and providing an initial
fix.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman