linux/drivers, branch v3.11.5

bcache: Fix a null ptr deref regression

2013-10-14T01:14:32Z

commit 2fe80d3bbf1c8bd9efc5b8154207c8dd104e7306 upstream. Commit c0f04d88e46d ("bcache: Fix flushes in writeback mode") was fixing a reported data corruption bug, but it seems some last minute refactoring or rebasing introduced a null pointer deref. Signed-off-by: Kent Overstreet Reported-by: Gabriel de Perthuis Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

net: qmi_wwan: add new Qualcomm devices

2013-10-14T01:14:32Z

commit 0470667caa8261beb8a9141102b04a5357dd45b5 upstream. Adding the device list from the Windows driver description files included with a new Qualcomm MDM9615 based device, "Alcatel-sbell ASB TL131 TDD LTE", from China Mobile. This device is tested and verified to work. The others are assumed to work based on using the same Windows driver. Many of these devices support multiple QMI/wwan ports, requiring multiple interface matching entries. All devices are composite, providing a mix of one or more serial, storage or Android Debug Brigde functions in addition to the wwan function. This device list included an update of one previously known device, which was incorrectly assumed to have a Gobi 2K layout. This is corrected. Reported-by: 王康 Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

HID: uhid: allocate static minor

2013-10-14T01:14:32Z

commit 19872d20c890073c5207d9e02bb8f14d451a11eb upstream. udev has this nice feature of creating "dead" /dev/ device-nodes if it finds a devnode: modalias. Once the node is accessed, the kernel automatically loads the module that provides the node. However, this requires udev to know the major:minor code to use for the node. This feature was introduced by: commit 578454ff7eab61d13a26b568f99a89a2c9edc881 Author: Kay Sievers Date: Thu May 20 18:07:20 2010 +0200 driver core: add devname module aliases to allow module on-demand auto-loading However, uhid uses dynamic minor numbers so this doesn't actually work. We need to load uhid to know which minor it's going to use. Hence, allocate a static minor (just like uinput does) and we're good to go. Reported-by: Tom Gundersen Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: uhid: add devname module alias

2013-10-14T01:14:32Z

commit 60cbd53e4bf623fe978e6f23a6da642e730fde3a upstream. For simple device node creation, add the devname module alias. Signed-off-by: Marcel Holtmann Reviewed-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: add Holtek USB ID 04d9:a081 SHARKOON DarkGlider

2013-10-14T01:14:32Z

commit 7da7cbbbeb60e0939fecdf9723b388136c175e5c upstream. Added id, bindings and comments for Holtek USB ID 04d9:a081 SHARKOON DarkGlider Gaming mouse to use the same corrections of the report descriptor as Holtek 04d9:a04a. As the mouse exceed HID_MAX_USAGES at the same offsets in the reported descriptor. Tested on the hardware. Signed-off-by: Anders F. U. Kiær Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

HID: roccat: add support for KonePureOptical v2

2013-10-14T01:14:32Z

commit a4be0ed39f2b1ea990804ea54e39bc42d17ed5a5 upstream. KonePureOptical is a KonePure with different sensor. Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

mmc: fix null pointer use in mmc_blk_remove_req

2013-10-14T01:14:32Z

commit 8efb83a2f8518a6ffcc074177f8d659c5165ef37 upstream. A previous commit (fdfa20c1631210d0) reordered the shutdown sequence in mmc_blk_remove_req. However, mmc_cleanup_queue is now called before we get the card pointer, and mmc_cleanup_queue sets mq->card to NULL. This patch moves the card pointer assignment before mmc_cleanup_queue. Signed-off-by: Franck Jullien Signed-off-by: Chris Ball Cc: Adrian Hunter Signed-off-by: Greg Kroah-Hartman

HID: wiimote: fix FF deadlock

2013-10-14T01:14:31Z

commit f50f9aabf32db7414551ffdfdccc71be5f3d6e7d upstream. The input core has an internal spinlock that is acquired during event injection via input_event() and friends but also held during FF callbacks. That means, there is no way to share a lock between event-injection and FF handling. Unfortunately, this is what is required for wiimote state tracking and what we do with state.lock and input->lock. This deadlock can be triggered when using continuous data reporting and FF on a wiimote device at the same time. I takes me at least 30m of stress-testing to trigger it but users reported considerably shorter times (http://bpaste.net/show/132504/) when using some gaming-console emulators. The real problem is that we have two copies of internal state, one in the wiimote objects and the other in the input device. As the input-lock is not supposed to be accessed from outside of input-core, we have no other chance than offloading FF handling into a worker. This actually works pretty nice and also allows to implictly merge fast rumble changes into a single request. Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF responsiveness. Initial tests were fine so lets fix the race first and if it turns out to be too slow we can always handle FF out-of-band and skip the queue-worker. Reported-by: Thomas Schneider Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman

drm/nouveau/bios/init: stub opcode 0xaa

2013-10-14T01:14:31Z

commit 5495e39fb3695182b9f2a72fe4169056cada37a1 upstream. Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman

ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler()

2013-10-14T01:14:31Z

commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream. This patch fixes the issues indicated by the test results that ipmi_msg_handler() is invoked in atomic context. BUG: scheduling while atomic: kipmi0/18933/0x10000100 Modules linked in: ipmi_si acpi_ipmi ... CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G AW 3.10.0-rc7+ #2 Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010 ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8 ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4 0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8 Call Trace: [] dump_stack+0x19/0x1b [] __schedule_bug+0x46/0x54 [] __schedule+0x83/0x59c [] __cond_resched+0x22/0x2d [] _cond_resched+0x14/0x1d [] mutex_lock+0x11/0x32 [] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58 [] ipmi_msg_handler+0x23/0x166 [ipmi_si] [] deliver_response+0x55/0x5a [] handle_new_recv_msgs+0xb67/0xc65 [] ? read_tsc+0x9/0x19 [] ? _raw_spin_lock_irq+0xa/0xc [] ipmi_thread+0x5c/0x146 [ipmi_si] ... Also Tony Camuso says: We were getting occasional "Scheduling while atomic" call traces during boot on some systems. Problem was first seen on a Cisco C210 but we were able to reproduce it on a Cisco c220m3. Setting CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device. ================================= [ INFO: inconsistent lock state ] 2.6.32-415.el6.x86_64-debug-splck #1 --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes: (&ipmi_device->tx_msg_lock){+.?...}, at: [] ipmi_msg_handler+0x71/0x126 {SOFTIRQ-ON-W} state was registered at: [] __lock_acquire+0x63c/0x1570 [] lock_acquire+0xa4/0x120 [] __mutex_lock_common+0x4c/0x400 [] mutex_lock_nested+0x4a/0x60 [] acpi_ipmi_space_handler+0x11b/0x234 [] acpi_ev_address_space_dispatch+0x170/0x1be The fix implemented by this change has been tested by Tony: Tested the patch in a boot loop with lockdep debug enabled and never saw the problem in over 400 reboots. Reported-and-tested-by: Tony Camuso Signed-off-by: Lv Zheng Reviewed-by: Huang Ying Signed-off-by: Rafael J. Wysocki Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman