linux/drivers/staging, branch v3.2.15

staging: r8712u: Fix regression in signal level after commit c6dc001

2012-04-02T16:52:29Z

commit da3e6ec2f443ac00aa623c5921e3521f5f38efe4 upstream. In commit c6dc001 "staging: r8712u: Merging Realtek's latest (v2.6.6). Various fixes", the returned qual.qual member of the iw_statistics struct was changed. For strong signals, this change made no difference; however for medium and weak signals it results in a low signal that shows considerable fluctuation, When using wicd for a medium-strength AP, the value reported in the status line is reduced from 100% to 60% by this bug. This problem is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42826. Reported-and-tested-by: Robert Crawford Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman

staging: r8712u: Fix regression introduced by commit a5ee652

2012-04-02T16:52:15Z

commit 9f4bc8cf3fe750ed093856a5f5d41c11cc12ad22 upstream. In commit a5ee652 "staging: r8712u: Interface-state not fully tracked", the private boolean "bup" was set false when the interface was brought down, as that seemed appropriate. This change has not caused any problems when using NetworkManager or manual control of the device; however, when wicd control is used, there is a locking problem in wpa_supplicant, as shown in https://bugzilla.kernel.org/show_bug.cgi?id=42818. This fix reverts the only code change in commit a5ee652. My analysis is that "bup" is badly named. In its present form, it seems to indicate the up/down state of the device, but its usage is more consistent with an initialized/uninitialized state. That problem will be addressed in a later patch. Note: Commit 8c213fa, which introdued asynchronous firmware loading for this driver, exposed this bug to a greater extent. That bug is addressed in the next patch in this series. This bug is also responsible for the bug in https://bugzilla.kernel.org/show_bug.cgi?id=42815. and this bug is also part of the problems discussed at https://bugs.archlinux.org/task/27996#comment89950. Tested-by: Alberto Lago Ballesteros Tested-by: Adrian Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman

staging: r8712u: Add missing initialization and remove configuration parameter CONFIG_R8712_AP

2012-04-02T16:52:10Z

commit 073863432f7eaa23c7c09733414d4be2eabf5eef upstream. When this driver was upgraded to the vendor 20100831 version in commit 93c55dda092c7 et al,, one listhead initialization was missed. This broke complete operation of the driver whenever AP mode was enabled. This fixes https://bugs.archlinux.org/task/27996. The configuration parameter R8712_AP is misleading as the driver cannot function as an AP without a heavily hacked version of hostapd. Thus, it makes sense to remove the parameter; however the code and data configured for the option is left in. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman

staging: zcache: avoid AB-BA deadlock condition

2012-04-02T16:52:08Z

commit cfbc6a92212e74b07aa76c9e2f20c542e36077fb upstream. Commit 9256a47 fixed a deadlock condition, being sure that the buddy list spinlock is always taken before the page spinlock. However in zbud_free_and_delist() locking order is the opposite (page lock -> list lock). Possible unsafe locking scenario (reported by lockdep): CPU0 CPU1 ---- ---- lock(&(&zbpg->lock)->rlock); lock(zbud_budlists_spinlock); lock(&(&zbpg->lock)->rlock); lock(zbud_budlists_spinlock); Fix by grabbing the locks in opposite order in zbud_free_and_delist(). Signed-off-by: Andrea Righi Signed-off-by: Greg Kroah-Hartman

media: staging: lirc_serial: Do not assume error codes returned by request_irq()

2012-03-12T19:31:39Z

commit affc9a0d59ac49bd304e2137bd5e4ffdd6fdfa52 upstream. lirc_serial_probe() must fail if request_irq() returns an error, even if it isn't EBUSY or EINVAL, Signed-off-by: Ben Hutchings Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman

media: staging: lirc_serial: Fix deadlock on resume failure

2012-03-12T19:31:39Z

commit 1ff1d88e862948ae5bfe490248c023ff8ac2855d upstream. A resume function cannot remove the device it is resuming! Signed-off-by: Ben Hutchings Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman

media: staging: lirc_serial: Free resources on failure paths of lirc_serial_probe()

2012-03-12T19:31:39Z

commit c8e57e1b766c2321aa76ee5e6878c69bd2313d62 upstream. Failure to allocate the I/O region leaves the IRQ allocated. A later failure leaves them both allocated. Reported-by: Torsten Crass Signed-off-by: Ben Hutchings Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman

media: staging: lirc_serial: Fix init/exit order

2012-03-12T19:31:39Z

commit 9105b8b200410383d0854bbe237ee385d7d33ba6 upstream. Currently the module init function registers a platform_device and only then allocates its IRQ and I/O region. This allows allocation to race with the device's suspend() function. Instead, allocate resources in the platform driver's probe() function and free them in the remove() function. The module exit function removes the platform device before the character device that provides access to it. Change it to reverse the order of initialisation. Signed-off-by: Ben Hutchings Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Nieder Signed-off-by: Greg Kroah-Hartman

zcache: fix deadlock condition

2012-02-13T19:17:04Z

commit 9256a4789be3dae37d00924c03546ba7958ea5a3 upstream. I discovered this deadlock condition awhile ago working on RAMster but it affects zcache as well. The list spinlock must be locked prior to the page spinlock and released after. As a result, the page copy must also be done while the locks are held. Applies to 3.2. Konrad, please push (via GregKH?)... this is definitely a bug fix so need not be pushed during a -rc0 window. Signed-off-by: Dan Magenheimer Acked-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman

zcache: Set SWIZ_BITS to 8 to reduce tmem bucket lock contention.

2012-02-13T19:17:04Z

commit e8b4553457e78bcff90f70a31212a40a8fd4f0db upstream. SWIZ_BITS > 8 results in a much larger number of "tmem_obj" allocations, likely one per page-placed-in-frontswap. The tmem_obj is not huge (roughly 100 bytes), but it is large enough to add a not-insignificant memory overhead to zcache. The SWIZ_BITS=8 will get roughly the same lock contention without the space wastage. The effect of SWIZ_BITS can be thought of as "2^SWIZ_BITS is the number of unique oids that be generated" (This concept is limited to frontswap's use of tmem). Acked-by: Seth Jennings Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman