commit be47c9e70ec3e4687531f29e3d290ef4f9b5ed35 Author: Greg Kroah-Hartman Date: Thu Jun 13 09:48:06 2013 -0700 Linux 3.4.49 commit bc4d36c41f16a66c320fd0282110ddc82aa1eb09 Author: Steven Rostedt Date: Fri Jun 7 17:02:08 2013 +0800 ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream. As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the ftrace_pid_fops is defined when DYNAMIC_FTRACE is not. Signed-off-by: Steven Rostedt Cc: Namhyung Kim [ lizf: adjust context ] Signed-off-by: Li Zefan Signed-off-by: Greg Kroah-Hartman commit 3a22cc7f184b77731816e55662cd12f0c3d24d56 Author: Namhyung Kim Date: Fri Jun 7 17:01:16 2013 +0800 tracing: Fix possible NULL pointer dereferences commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d upstream. Currently set_ftrace_pid and set_graph_function files use seq_lseek for their fops. However seq_open() is called only for FMODE_READ in the fops->open() so that if an user tries to seek one of those file when she open it for writing, it sees NULL seq_file and then panic. It can be easily reproduced with following command: $ cd /sys/kernel/debug/tracing $ echo 1234 | sudo tee -a set_ftrace_pid In this example, GNU coreutils' tee opens the file with fopen(, "a") and then the fopen() internally calls lseek(). Link: http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.org Signed-off-by: Namhyung Kim Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Signed-off-by: Steven Rostedt [ lizf: adjust context ] Signed-off-by: Li Zefan Signed-off-by: Greg Kroah-Hartman commit ce840e2f7825bfd240782dc209c2f2b8db514287 Author: Patrik Jakobsson Date: Thu Apr 25 22:23:36 2013 +0200 drm/gma500: Increase max resolution for mode setting commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream. By having a higher max resolution we can now set up a virtual framebuffer that spans several monitors. 4096 should be ok since we're gen 3 or higher and should be enough for most dual head setups. Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-modesetting/+bug/1169147 Signed-off-by: Patrik Jakobsson Signed-off-by: Greg Kroah-Hartman commit 800d5c2cab62e3aef15ec3d7bf03e859b9e95a44 Author: Ying Xue Date: Mon Aug 6 17:46:37 2012 +0800 USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream. Pointers should not be compared to plain integers. Quiets the sparse warning: warning: Using plain integer as NULL pointer Signed-off-by: Ying Xue Cc: Lotfi Manseur Signed-off-by: Greg Kroah-Hartman commit 1bcf5bcf70fb6f316d4eba792d103af602cb3514 Author: Jan Beulich Date: Wed Feb 6 10:30:38 2013 -0500 xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}() commit 51ac8893a7a51b196501164e645583bf78138699 upstream. ... as being guest triggerable (e.g. by invoking XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable). This is CVE-2013-0231 / XSA-43. Also make the two messages uniform in both their wording and severity. Signed-off-by: Jan Beulich Acked-by: Ian Campbell Reviewed-by: Konrad Rzeszutek Wilk [stable tree: Added two extra #include files] Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit 57e90e2cc1e073cd9a595c86d64717a07b6c85ee Author: Ben Mesman Date: Tue Apr 16 20:00:28 2013 +0200 drm/i915: no lvds quirk for hp t5740 commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream. Last year, a patch was made for the "HP t5740e Thin Client" (see http://lists.freedesktop.org/archives/dri-devel/2012-May/023245.html). This device reports an lvds panel, but does not really have one. The predecessor of this device is the "hp t5740", which also does not have an lvds panel. This patch will add the same quirk for this device. Signed-off-by: Ben Mesman Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 15360c3f303d9d12b36611b2721a68451e9f6424 Author: Egbert Eich Date: Tue Jun 4 17:13:21 2013 +0200 drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC. commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream. In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used for DDC. Thus the code will always have to rely on a LVDS panel mode supplied by VBT. In most cases this succeeds, so this didn't get detected for quite a while. This regression seems to have been introduced in commit f899fc64cda8569d0529452aafc0da31c042df2e Author: Chris Wilson Date: Tue Jul 20 15:44:45 2010 -0700 drm/i915: use GMBUS to manage i2c links Signed-off-by: Egbert Eich Reviewed-by: Chris Wilson [danvet: Add note about which commit likely introduced this issue.] Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 7cfaeaba14a0fd625d96ba35fda75c8eed60a368 Author: Huacai Chen Date: Tue May 21 06:23:43 2013 +0000 drm: fix a use-after-free when GPU acceleration disabled commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream. When GPU acceleration is disabled, drm_vblank_cleanup() will free the vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. But we found that drm_vblank_post_modeset() may be called after the cleanup, which use vblank_refcount and vblank_inmodeset. And this will cause a kernel panic. Fix this by return immediately if dev->num_crtcs is zero. This is the same thing that drm_vblank_pre_modeset() does. Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): [ 62.628906] [] drm_vblank_post_modeset+0x34/0xb4 [ 62.628906] [] atombios_crtc_dpms+0xb4/0x174 [ 62.628906] [] atombios_crtc_commit+0x18/0x38 [ 62.628906] [] drm_crtc_helper_set_mode+0x304/0x3cc [ 62.628906] [] drm_crtc_helper_set_config+0x6d8/0x988 [ 62.628906] [] drm_fb_helper_set_par+0x94/0x104 [ 62.628906] [] fbcon_init+0x424/0x57c [ 62.628906] [] visual_init+0xb8/0x118 [ 62.628906] [] take_over_console+0x238/0x384 [ 62.628906] [] fbcon_takeover+0x7c/0xdc [ 62.628906] [] notifier_call_chain+0x44/0x94 [ 62.628906] [] __blocking_notifier_call_chain+0x48/0x68 [ 62.628906] [] register_framebuffer+0x228/0x260 [ 62.628906] [] drm_fb_helper_single_fb_probe+0x260/0x314 [ 62.628906] [] drm_fb_helper_initial_config+0x200/0x234 [ 62.628906] [] radeon_fbdev_init+0xd4/0xf4 [ 62.628906] [] radeon_modeset_init+0x9bc/0xa18 [ 62.628906] [] radeon_driver_load_kms+0xdc/0x12c [ 62.628906] [] drm_get_pci_dev+0x148/0x238 [ 62.628906] [] local_pci_probe+0x5c/0xd0 [ 62.628906] [] work_for_cpu_fn+0x1c/0x30 [ 62.628906] [] process_one_work+0x274/0x3bc [ 62.628906] [] process_scheduled_works+0x24/0x44 [ 62.628906] [] worker_thread+0x31c/0x3f4 [ 62.628906] [] kthread+0x88/0x90 [ 62.628906] [] kernel_thread_helper+0x10/0x18 Signed-off-by: Huacai Chen Signed-off-by: Binbin Zhou Reviewed-by: Michel Dänzer Acked-by: Paul Menzel Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit fa8defe62cc9791fcc83759d9d27fef0fca921b1 Author: Guenter Roeck Date: Wed Jun 5 14:09:30 2013 -0700 hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617 commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream. On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected as LM84. Strengthen detection sufficiently enough to avoid this misdetection. Also improve detection for ADM1021. Modeled after chip detection code in sensors-detect command. Signed-off-by: Guenter Roeck Tested-by: Jean Delvare Acked-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 36247d18978750da120dbded4d23c74bb9468549 Author: Alex Deucher Date: Mon Jun 3 10:32:40 2013 -0400 drm/radeon: don't allow audio on DCE6 commit 1cbcca302a318499f20a512847c5d6a510c08c35 upstream. It's not supported yet. Fixes display issues when users force it on. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f6321eec602f4eed6a78b0cbb91514d7c4cb74b7 Author: Adis Hamzić Date: Sun Jun 2 16:47:54 2013 +0200 radeon: Fix system hang issue when using KMS with older cards commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream. The current radeon driver initialization routines, when using KMS, are written so that the IRQ installation routine is called before initializing the WB buffer and the CP rings. With some ASICs, though, the IRQ routine tries to access the GFX_INDEX ring causing a call to RREG32 with the value of -1 in radeon_fence_read. This, in turn causes the system to completely hang with some cards, requiring a hard reset. A call stack that can cause such a hang looks like this (using rv515 ASIC for the example here): * rv515_init (rv515.c) * radeon_irq_kms_init (radeon_irq_kms.c) * drm_irq_install (drm_irq.c) * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c) * rs600_irq_process (rs600.c) * radeon_fence_process - due to SW interrupt (radeon_fence.c) * radeon_fence_read (radeon_fence.c) * hang due to RREG32(-1) The patch moves the IRQ installation to the card startup routine, after the ring has been initialized, but before the IRQ has been set. This fixes the issue, but requires a check to see if the IRQ is already installed, as is the case in the system resume codepath. I have tested the patch on three machines using the rv515, the rv770 and the evergreen ASIC. They worked without issues. This seems to be a known issue and has been reported on several bug tracking sites by various distributions (see links below). Most of reports recommend booting the system with KMS disabled and then enabling KMS by reloading the radeon module. For some reason, this was indeed a usable workaround, however, UMS is now deprecated and disabled by default. Bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=845745 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789 https://bbs.archlinux.org/viewtopic.php?id=156964 Signed-off-by: Adis Hamzić Signed-off-by: Alex Deucher commit ed753efb898ba2929d19f9cc050c432be54aeae7 Author: Gavin Shan Date: Wed Jun 5 14:25:50 2013 +0000 powerpc/eeh: Don't check RTAS token to get PE addr commit b8b3de224f194005ad87ede6fd022fcc2bef3b1a upstream. RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2" are used to retrieve the PE address according to PCI address, which made up of domain/bus/slot/function. If we don't have those 2 tokens, the domain/bus/slot/function would be used as the address for EEH RTAS operations. Some older f/w might not have those 2 tokens and that blocks the EEH functionality to be initialized. It was introduced by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization"). The patch skips the check on those 2 tokens so we can bring up EEH functionality successfully. And domain/bus/slot/function will be used as address for EEH RTAS operations. Reported-by: Robert Knight Signed-off-by: Gavin Shan Tested-by: Robert Knight Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 06f3ee48d0f0c2a531f7c5ff6355f9ccee32b20d Author: Ash Willis Date: Wed May 29 01:27:59 2013 +0000 ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6 commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream. This patch addresses kernel bug 56661. BIOS reports an incorrect backlight value, causing the driver to switch off the backlight completely during startup. This patch ignores the incorrect value from BIOS. References: https://bugzilla.kernel.org/show_bug.cgi?id=56661 Signed-off-by: Ash Willis Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 871483faa88417bcec82ed20050c758cbf65a5ca Author: Alex Hung Date: Tue May 28 02:05:09 2013 +0000 ACPI / video: ignore BIOS initial backlight value for HP m4 commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream. On HP m4 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References: https://bugs.launchpad.net/bugs/1184501 Signed-off-by: Alex Hung Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c88c5035b860bc6f2e6d3c52194af1930f56b81e Author: Johan Hovold Date: Tue Jun 4 18:50:31 2013 +0200 USB: mos7720: fix hardware flow control commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream. The register access to enable hardware flow control depends on the device port number and not the port minor number. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 515901ec9c2b6adc95e70c22f1c4e00427c4b67c Author: Johan Hovold Date: Mon May 27 14:44:43 2013 +0200 USB: mos7720: fix message timeouts commit 849513a7809175420d353625b6f651d961e99d49 upstream. The control and bulk-message timeouts are specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f856f08e406a4c32e3c60a6e0761027902c44bb1 Author: Johan Hovold Date: Mon May 27 14:44:39 2013 +0200 USB: mos7720: fix DMA to stack commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream. The read_mos_reg function is called with stack-allocated buffers, which must not be used for control messages. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 30871ae102c41f1695d6de037e13ec40a1d7498a Author: Alan Stern Date: Tue May 28 14:03:10 2013 -0400 USB: revert periodic scheduling bugfix commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream. This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d (USB: EHCI: fix bug in scheduling periodic split transfers). The commit was valid -- it fixed a real bug -- but the periodic scheduler in ehci-hcd is in such bad shape (especially the part that handles split transactions) that fixing one bug is very likely to cause another to surface. That's what happened in this case; the result was choppy and noisy playback on certain 24-bit audio devices. The only real fix will be to rewrite this entire section of code. My next project... This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110. Thanks to Tim Richardson for extra testing and feedback, and to Joseph Salisbury and Tyson Tan for tracking down the original source of the problem. Signed-off-by: Alan Stern CC: Joseph Salisbury CC: Tim Richardson Signed-off-by: Greg Kroah-Hartman commit 23269c0adf51bd719249016080d896f888d57c92 Author: Johan Hovold Date: Mon May 27 14:44:37 2013 +0200 USB: serial: fix Treo/Kyocera interrrupt-in urb context commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream. The first and second interrupt-in urbs are swapped for some Treo/Kyocera devices, but the urb context was never updated with the new port. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit d3a677e63a19355155ff83acf46d1ede8845ffaf Author: Johan Hovold Date: Thu Jun 6 13:32:47 2013 +0200 USB: whiteheat: fix broken port configuration commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream. When configuring the port (e.g. set_termios) the port minor number rather than the port number was used in the request (and they only coincide for minor number 0). Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 617d12d484ae22a85d6da8e94cf55dd91594fd87 Author: Robert Butora Date: Fri May 31 18:09:51 2013 +0300 USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream. The patch adds a new HIDCOM device and does not affect other devices driven by the cypress_M8 module. Changes are: - add VendorID ProductID to device tables - skip unstable speed check because FRWD uses 115200bps - skip reset at probe which is an issue workaround for this particular device. Signed-off-by: Robert Butora Signed-off-by: Greg Kroah-Hartman commit 0279e6708d667ed8557dbb47e3600ce8ff2b35c5 Author: Johan Hovold Date: Mon May 27 14:44:38 2013 +0200 USB: visor: fix initialisation of Treo/Kyocera devices commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3 upstream. Fix regression introduced by commit 214916f2e ("USB: visor: reimplement using generic framework") which broke initialisation of Treo/Kyocera devices that re-mapped bulk-in endpoints. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fd02023627e25662b676f21ad86443b440bd7102 Author: Johan Hovold Date: Mon May 27 14:44:41 2013 +0200 USB: ark3116: fix control-message timeout commit 634371911730a462626071065b64cd6e1fe213e0 upstream. The control-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9df24541450414bc7117bb05ce6ab54834f47289 Author: Johan Hovold Date: Tue Jun 4 18:50:29 2013 +0200 USB: keyspan: fix bogus array index commit a07088098a650267b2eda689538133a324b9523f upstream. The outcont_endpoints array was indexed using the port minor number (which can be greater than the array size) rather than the device port number. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit af90f015629d67c1172aff6baffdb99a0db3ad95 Author: Johan Hovold Date: Mon May 27 14:44:42 2013 +0200 USB: iuu_phoenix: fix bulk-message timeout commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7 upstream. The bulk-message timeout is specified in milliseconds and should not depend on HZ. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 395801f773ba978d4c0d3cb0675e534624ade228 Author: Takashi Iwai Date: Wed Jun 5 08:35:26 2013 +0200 ALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270 commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993 upstream. USB audio driver spews an error message when probing Logitech HD webcam c270: ALSA mixer.c:1300 usb_audio: Warning! Unlikely big volume range (=6144), cval->res is probably wrong. ALSA mixer.c:1304 usb_audio: [5] FU [Mic Capture Volume] ch = 1, val = 1536/7680/1 Obviously the device needs a fixed volume resolution (cval->res = 384) like other Logitech devices. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=821735 Reported-and-tested-by: Cristian Rodríguez Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8e411de6df1711a8d930373bbccf044ba4573bcc Author: Takashi Iwai Date: Tue Jun 4 16:02:54 2013 +0200 ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89 upstream. ... instead of applying to all interfaces. Reference: http://forums.gentoo.org/viewtopic-p-6886404.html Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6ba9458dbba742c68f123b7281bd2e382366b400 Author: Clemens Ladisch Date: Sun Jun 2 19:49:07 2013 +0200 ALSA: usb-audio: fix Roland/Cakewalk UM-3G support commit a0c6d309c6df14655f9962f666d1da96318b0b7c upstream. Commit 927c9423dd5f2d1c0b93d5e694ab84b4a5559713 (ALSA: usb-audio: add Edirol UM-3G support) used a wrong quirk type, which would make the driver refuse to attach with the error message "MIDIStreaming interface descriptor not found". Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5c29245cb650479f77b33453194e1e834029f2f9 Author: Vladimir Murzin Date: Tue Apr 9 22:33:31 2013 +0400 xhci: fix list access before init commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream. If for whatever reason we fall into fail path in xhci_mem_init() before bw table gets initialized we may access the uninitialized lists in xhci_mem_cleanup(). Check for bw table before traversing lists in cleanup routine. This patch should be backported to kernels as old as 3.2, that contain the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store information about roothubs and TTs." Reported-by: Sergey Dyasly Tested-by: Sergey Dyasly Signed-off-by: Vladimir Murzin Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit c5d2935c1ce3d8c8bde02b744c55c10953d411dd Author: Sergio Aguirre Date: Thu Apr 4 10:32:13 2013 -0700 xhci-mem: init list heads at the beginning of init commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream. It is possible that we fail on xhci_mem_init, just before doing the INIT_LIST_HEAD, and calling xhci_mem_cleanup. Problem is that, the list_for_each_entry_safe macro, assumes list heads are initialized (not NULL), and dereferences their 'next' pointer, causing a kernel panic if this is not yet initialized. Let's protect from that by moving inits to the beginning. This patch should be backported to kernels as old as 3.2, that contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test USB2 software LPM". Signed-off-by: Sergio Aguirre Acked-by: David Cohen Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 6eb953e922b384e3b42418fdbc44db4da3dfea65 Author: Tony Camuso Date: Thu Feb 21 16:11:27 2013 -0500 xhci - correct comp_mode_recovery_timer on return from hibernate commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream. Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware) was a workaround for systems using the SN65LVPE502CP, controller, but it introduced a bug in resume from hibernate. The fix created a timer, comp_mode_recovery_timer, which is deleted from a timer list when xhci_suspend() is called. However, the hibernate image, including the timer list containing the comp_mode_recovery_timer, had already been saved before the timer was deleted. Upon resume from hibernate, the list containing the comp_mode_recovery_timer is restored from the image saved to disk, and xhci_resume(), assuming that the timer had been deleted by xhci_suspend(), makes a call to compliance_mode_recoery_timer_init(), which creates a new instance of the comp_mode_recovery_timer and attempts to place it into the same list in which it is already active, thus corrupting the list during the list_add() call. At this point, a call trace is emitted indicating the list corruption. Soon afterward, the system locks up, the watchdog times out, and the ensuing NMI crashes the system. The problem did not occur when resuming from suspend. In suspend, the image in RAM remains exactly as it was when xhci_suspend() deleted the comp_mode_recovery_timer, so there is no problem when xhci_resume() creates a new instance of this timer and places it in the still empty list. This patch avoids the problem by deleting the timer in xhci_resume() when resuming from hibernate. Now xhci_resume() can safely make the call to create a new instance of this timer, whether returning from suspend or hibernate. Thanks to Alan Stern for his help with understanding the problem. [Sarah reworked this patch to cover the case where the xHCI restore register operation fails, and (temp & STS_SRE) is true (and we re-init the host, including re-init for the compliance mode), but hibernate is false. The original patch would have caused list corruption in this case.] This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Tony Camuso Tested-by: Tony Camuso Acked-by: Don Zickus Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit 37c1d9ba127ed6735ae4990f9db62c4d8d81a4d3 Author: Bjørn Mork Date: Thu Jun 6 12:57:24 2013 +0200 USB: option: blacklist network interface on Huawei E1820 commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream. The mode used by Windows for the Huawei E1820 will use the same ff/ff/ff class codes for both serial and network functions. Reported-by: Graham Inggs Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman