kernel/linux.git/drivers, branch v3.12.62

cdc_ncm: workaround for EM7455 "silent" data interface

2016-07-21T06:36:12+00:00

[ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ] Several Lenovo users have reported problems with their Sierra Wireless EM7455 modem. The driver has loaded successfully and the MBIM management channel has appeared to work, including establishing a connection to the mobile network. But no frames have been received over the data interface. The problem affects all EM7455 and MC7455, and is assumed to affect other modems based on the same Qualcomm chipset and baseband firmware. Testing narrowed the problem down to what seems to be a firmware timing bug during initialization. Adding a short sleep while probing is sufficient to make the problem disappear. Experiments have shown that 1-2 ms is too little to have any effect, while 10-20 ms is enough to reliably succeed. Reported-by: Stefan Armbruster Reported-by: Ralph Plawetzki Reported-by: Andreas Fett Reported-by: Rasmus Lerdorf Reported-by: Samo Ratnik Reported-and-tested-by: Aleksander Morgado Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby

HID: elo: kill not flush the work

2016-07-21T06:36:11+00:00

commit ed596a4a88bd161f868ccba078557ee7ede8a6ef upstream. Flushing a work that reschedules itself is not a sensible operation. It needs to be killed. Failure to do so leads to a kernel panic in the timer code. Signed-off-by: Oliver Neukum Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands

2016-07-21T06:36:10+00:00

commit 93a2001bdfd5376c3dc2158653034c20392d15c5 upstream. This patch validates the num_values parameter from userland during the HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter leading to a heap overflow. Signed-off-by: Scott Bauer Signed-off-by: Jiri Kosina Signed-off-by: Jiri Slaby

base: make module_create_drivers_dir race-free

2016-07-21T06:36:09+00:00

commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 upstream. Modules which register drivers via standard path (driver_register) in parallel can cause a warning: WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80 sysfs: cannot create duplicate filename '/module/saa7146/drivers' Modules linked in: hexium_gemini(+) mxb(+) ... ... Call Trace: ... [] sysfs_warn_dup+0x62/0x80 [] sysfs_create_dir_ns+0x77/0x90 [] kobject_add_internal+0xb4/0x340 [] kobject_add+0x68/0xb0 [] kobject_create_and_add+0x31/0x70 [] module_add_driver+0xc3/0xd0 [] bus_add_driver+0x154/0x280 [] driver_register+0x60/0xe0 [] __pci_register_driver+0x60/0x70 [] saa7146_register_extension+0x64/0x90 [saa7146] [] hexium_init_module+0x11/0x1000 [hexium_gemini] ... As can be (mostly) seen, driver_register causes this call sequence: -> bus_add_driver -> module_add_driver -> module_create_drivers_dir The last one creates "drivers" directory in /sys/module/<...>. When this is done in parallel, the directory is attempted to be created twice at the same time. This can be easily reproduced by loading mxb and hexium_gemini in parallel: while :; do modprobe mxb & modprobe hexium_gemini wait rmmod mxb hexium_gemini saa7146_vv saa7146 done saa7146 calls pci_register_driver for both mxb and hexium_gemini, which means /sys/module/saa7146/drivers is to be created for both of them. Fix this by a new mutex in module_create_drivers_dir which makes the test-and-create "drivers" dir atomic. I inverted the condition and removed 'return' to avoid multiple unlocks or a goto. Signed-off-by: Jiri Slaby Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed) Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

SCSI: Increase REPORT_LUNS timeout

2016-07-21T06:36:08+00:00

commit b39c9a661b9bc77e064cade26cf913a1d4255d55 upstream. This patch fixes an issue seen with an IBM 2145 (SVC) where, following an error injection test which results in paths going offline, when they came back online, the path would timeout the REPORT_LUNS issued during the scan. This timeout situation continued until retries were expired, resulting in falling back to a sequential LUN scan. Then, since the target responds with PQ=1, PDT=0 for all possible LUNs, due to the way the sequential LUN scan code works, we end up adding 512 LUNs for each target, when there is really only a small handful of LUNs that are actually present. This patch increases the timeout used on the REPORT_LUNS to 30 seconds. This patch solves the issue of 512 non existent LUNs showing up after this event. Signed-off-by: Brian King Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Jiri Slaby

EDAC: Remove arbitrary limit on number of channels

2016-07-21T06:36:08+00:00

commit c44696fff04ff62f65441afe9ea244b47653dd6d upstream. Currently set to "6", but the reset of the code will dynamically allocate as needed. We need to go to "8" today, but drop the check completely to save doing this again when we need even larger numbers. Signed-off-by: Tony Luck Acked-by: Aristeu Rozanski Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jiri Slaby

net/qlge: Avoids recursive EEH error

2016-07-21T06:36:07+00:00

commit 3275c0c6c522ab04afa14f80efdac6213c3883d6 upstream. One timer, whose handler keeps reading on MMIO register for EEH core to detect error in time, is started when the PCI device driver is loaded. MMIO register can't be accessed during PE reset in EEH recovery. Otherwise, the unexpected recursive error is triggered. The timer isn't closed that time if the interface isn't brought up. So the unexpected recursive error is seen during EEH recovery when the interface is down. This avoids the unexpected recursive EEH error by closing the timer in qlge_io_error_detected() before EEH PE reset unconditionally. The timer is started unconditionally after EEH PE reset in qlge_io_resume(). Also, the timer should be closed unconditionally when the device is removed from the system permanently in qlge_io_error_detected(). Reported-by: Shriya R. Kulkarni Signed-off-by: Gavin Shan Signed-off-by: David S. Miller Signed-off-by: Jiri Slaby

USB: usbfs: fix potential infoleak in devio

2016-07-21T06:36:05+00:00

commit 681fef8380eb818c0b845fca5d2ab1dcbab114ee upstream. The stack object “ci” has a total size of 8 bytes. Its last 3 bytes are padding bytes which are not initialized and leaked to userland via “copy_to_user”. Signed-off-by: Kangjie Lu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Jiri Slaby

scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands

2016-07-21T06:36:04+00:00

commit a621bac3044ed6f7ec5fa0326491b2d4838bfa93 upstream. When SCSI was written, all commands coming from the filesystem (REQ_TYPE_FS commands) had data. This meant that our signal for needing to complete the command was the number of bytes completed being equal to the number of bytes in the request. Unfortunately, with the advent of flush barriers, we can now get zero length REQ_TYPE_FS commands, which confuse this logic because they satisfy the condition every time. This means they never get retried even for retryable conditions, like UNIT ATTENTION because we complete them early assuming they're done. Fix this by special casing the early completion condition to recognise zero length commands with errors and let them drop through to the retry code. Cc: stable@vger.kernel.org Reported-by: Sebastian Parschauer Signed-off-by: James E.J. Bottomley Tested-by: Jack Wang Signed-off-by: Martin K. Petersen [ jwang: backport from upstream 4.7 to fix scsi resize issue ] Signed-off-by: Jack Wang Signed-off-by: Jiri Slaby

scsi: remove scsi_end_request

2016-07-21T06:36:03+00:00

commit bc85dc500f9df9b2eec15077e5046672c46adeaa upstream. By folding scsi_end_request into its only caller we can significantly clean up the completion logic. We can use simple goto labels now to only have a single place to finish or requeue command there instead of the previous convoluted logic. Signed-off-by: Christoph Hellwig Reviewed-by: Nicholas Bellinger Reviewed-by: Mike Christie Reviewed-by: Hannes Reinecke [jwang: backport to 3.12] Signed-off-by: Jack Wang Signed-off-by: Jiri Slaby