linux/drivers/staging, branch v3.2.18

staging: r8712u: Fix regression caused by commit 8c213fa

2012-05-11T12:15:04Z

commit 2080913e017ab9f88379d93fd09546ad95faf87b upstream. In commit 8c213fa "staging: r8712u: Use asynchronous firmware loading", the command to release the firmware was placed in the wrong routine. In combination with the bug introduced in commit a5ee652 "staging: r8712u: Interface-state not fully tracked", the driver attempts to upload firmware that had already been released. This bug is the source of one of the problems in https://bugs.archlinux.org/task/27996#comment89833. Tested-by: Alberto Lago Ballesteros Tested-by: Adrian Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings

staging: iio: hmc5843: Fix crash in probe function.

2012-04-22T22:30:59Z

commit 62d2feb9803f18c4e3c8a1a2c7e30a54df8a1d72 upstream. Fix crash after issuing: echo hmc5843 0x1e > /sys/class/i2c-dev/i2c-2/device/new_device [ 37.180999] device: '2-001e': device_add [ 37.188293] bus: 'i2c': add device 2-001e [ 37.194549] PM: Adding info for i2c:2-001e [ 37.200958] bus: 'i2c': driver_probe_device: matched device 2-001e with driver hmc5843 [ 37.210815] bus: 'i2c': really_probe: probing driver hmc5843 with device 2-001e [ 37.224884] HMC5843 initialized [ 37.228759] ------------[ cut here ]------------ [ 37.233612] kernel BUG at mm/slab.c:505! [ 37.237701] Internal error: Oops - BUG: 0 [#1] PREEMPT [ 37.243103] Modules linked in: [ 37.246337] CPU: 0 Not tainted (3.3.1-gta04+ #28) [ 37.251647] PC is at kfree+0x84/0x144 [ 37.255493] LR is at kfree+0x20/0x144 [ 37.259338] pc : [] lr : [] psr: 40000093 [ 37.259368] sp : de249cd8 ip : 0000000c fp : 00000090 [ 37.271362] r10: 0000000a r9 : de229eac r8 : c0236274 [ 37.276855] r7 : c09d6490 r6 : a0000013 r5 : de229c00 r4 : de229c10 [ 37.283691] r3 : c0f00218 r2 : 00000400 r1 : c0eea000 r0 : c00b4028 [ 37.290527] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 37.298095] Control: 10c5387d Table: 9e1d0019 DAC: 00000015 [ 37.304107] Process sh (pid: 91, stack limit = 0xde2482f0) [ 37.309844] Stack: (0xde249cd8 to 0xde24a000) [ 37.314422] 9cc0: de229c10 de229c00 [ 37.322998] 9ce0: de229c10 ffffffea 00000005 c0236274 de140a80 c00b4798 dec00080 de140a80 [ 37.331573] 9d00: c032f37c dec00080 000080d0 00000001 de229c00 de229c10 c048d578 00000005 [ 37.340148] 9d20: de229eac 0000000a 00000090 c032fa40 00000001 00000000 00000001 de229c10 [ 37.348724] 9d40: de229eac 00000029 c075b558 00000001 00000003 00000004 de229c10 c048d594 [ 37.357299] 9d60: 00000000 60000013 00000018 205b0007 37332020 3432322e 5d343838 c0060020 [ 37.365905] 9d80: de251600 00000001 00000000 de251600 00000001 c0065a84 de229c00 de229c48 [ 37.374481] 9da0: 00000006 0048d62c de229c38 de229c00 de229c00 de1f6c00 de1f6c20 00000001 [ 37.383056] 9dc0: 00000000 c048d62c 00000000 de229c00 de229c00 de1f6c00 de1f6c20 00000001 [ 37.391632] 9de0: 00000000 c048d62c 00000000 c0330164 00000000 de1f6c20 c048d62c de1f6c00 [ 37.400207] 9e00: c0330078 de1f6c04 c078d714 de189b58 00000000 c02ccfd8 de1f6c20 c0795f40 [ 37.408782] 9e20: c0238330 00000000 00000000 c02381a8 de1b9fc0 de1f6c20 de1f6c20 de249e48 [ 37.417358] 9e40: c0238330 c0236bb0 decdbed8 de7d0f14 de1f6c20 de1f6c20 de1f6c54 de1f6c20 [ 37.425933] 9e60: 00000000 c0238030 de1f6c20 c078d7bc de1f6c20 c02377ec de1f6c20 de1f6c28 [ 37.434509] 9e80: dee64cb0 c0236138 c047c554 de189b58 00000000 c004b45c de1f6c20 de1f6cd8 [ 37.443084] 9ea0: c0edfa6c de1f6c00 dee64c68 de1f6c04 de1f6c20 dee64cb8 c047c554 de189b58 [ 37.451690] 9ec0: 00000000 c02cd634 dee64c68 de249ef4 de23b008 dee64cb0 0000000d de23b000 [ 37.460266] 9ee0: de23b007 c02cd78c 00000002 00000000 00000000 35636d68 00333438 00000000 [ 37.468841] 9f00: 00000000 00000000 001e0000 00000000 00000000 00000000 00000000 0a10cec0 [ 37.477416] 9f20: 00000002 de249f80 0000000d dee62990 de189b40 c0234d88 0000000d c010c354 [ 37.485992] 9f40: 0000000d de210f28 000acc88 de249f80 0000000d de248000 00000000 c00b7bf8 [ 37.494567] 9f60: de210f28 000acc88 de210f28 000acc88 00000000 00000000 0000000d c00b7ed8 [ 37.503143] 9f80: 00000000 00000000 0000000d 00000000 0007fa28 0000000d 000acc88 00000004 [ 37.511718] 9fa0: c000e544 c000e380 0007fa28 0000000d 00000001 000acc88 0000000d 00000000 [ 37.520294] 9fc0: 0007fa28 0000000d 000acc88 00000004 00000001 00000020 00000002 00000000 [ 37.528869] 9fe0: 00000000 beab8624 0000ea05 b6eaebac 600d0010 00000001 00000000 00000000 [ 37.537475] [] (kfree+0x84/0x144) from [] (device_add+0x530/0x57c) [ 37.545806] [] (device_add+0x530/0x57c) from [] (iio_device_register+0x8c8/0x990) [ 37.555480] [] (iio_device_register+0x8c8/0x990) from [] (hmc5843_probe+0xec/0x114) [ 37.565338] [] (hmc5843_probe+0xec/0x114) from [] (i2c_device_probe+0xc4/0xf8) [ 37.574737] [] (i2c_device_probe+0xc4/0xf8) from [] (driver_probe_device+0x118/0x218) [ 37.584777] [] (driver_probe_device+0x118/0x218) from [] (bus_for_each_drv+0x4c/0x84) [ 37.594818] [] (bus_for_each_drv+0x4c/0x84) from [] (device_attach+0x78/0xa4) [ 37.604125] [] (device_attach+0x78/0xa4) from [] (bus_probe_device+0x28/0x9c) [ 37.613433] [] (bus_probe_device+0x28/0x9c) from [] (device_add+0x3f4/0x57c) [ 37.622650] [] (device_add+0x3f4/0x57c) from [] (i2c_new_device+0xf8/0x19c) [ 37.631805] [] (i2c_new_device+0xf8/0x19c) from [] (i2c_sysfs_new_device+0xb4/0x130) [ 37.641754] [] (i2c_sysfs_new_device+0xb4/0x130) from [] (dev_attr_store+0x18/0x24) [ 37.651611] [] (dev_attr_store+0x18/0x24) from [] (sysfs_write_file+0x10c/0x140) [ 37.661193] [] (sysfs_write_file+0x10c/0x140) from [] (vfs_write+0xb0/0x178) [ 37.670410] [] (vfs_write+0xb0/0x178) from [] (sys_write+0x3c/0x68) [ 37.678833] [] (sys_write+0x3c/0x68) from [] (ret_fast_syscall+0x0/0x3c) [ 37.687683] Code: 1593301c e5932000 e3120080 1a000000 (e7f001f2) [ 37.700775] ---[ end trace aaf805debdb69390 ]--- Client data was assigned to iio_dev structure in probe but in hmc5843_init_client function casted to private driver data structure which is wrong. Possibly calling mutex_init(&data->lock); corrupt data which the lead to above crash. Signed-off-by: Marek Belisko Acked-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

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