- 07 6月, 2013 2 次提交
-
-
由 Bjørn Mork 提交于
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: NGraham Inggs <graham.inggs@uct.ac.za> Signed-off-by: NBjørn Mork <bjorn@mork.no> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
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). Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 05 6月, 2013 5 次提交
-
-
由 Johan Hovold 提交于
Fix regression introduced by commit 143d9d96 ("USB: serial: add tiocmiwait subdriver operation") which made the ioctl operation return ENODEV rather than ENOIOCTLCMD when a subdriver TIOCMIWAIT implementation is missing. Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The register access to enable hardware flow control depends on the device port number and not the port minor number. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Remove the no longer used endpoint-array access completely. Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
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. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Remove bogus port-number check in open and close, which prevented this driver from being used with a minor number different from zero. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 6月, 2013 2 次提交
-
-
由 Richard Weinberger 提交于
The Option GTM681W uses a qualcomm chip and can be served by the qcserial device driver. Signed-off-by: NRichard Weinberger <richard@nod.at> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Robert Butora 提交于
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: NRobert Butora <robert.butora.fi@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 30 5月, 2013 1 次提交
-
-
由 Alan Stern 提交于
This patch adds some code that inadvertently got left out of commit c1fdb68e (USB: EHCI: changes related to qh_refresh()). The calls to qh_refresh() and qh_link_periodic() were taken out of qh_schedule(); therefore it is necessary to call these routines manually after calling qh_schedule(). Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: NOleksij Rempel <linux@rempel-privat.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 5月, 2013 14 次提交
-
-
由 Federico Manzan 提交于
Increase the current arbitrary limit for isocronous packet size to a value large enough to account for USB 3.0 super bandwidth streams, bMaxBurst (0~15 allowed, 1~16 packets) bmAttributes (bit 1:0, mult 0~2, 1~3 packets) so the size max for one USB 3 isocronous transfer is 1024 byte * 16 * 3 = 49152 byte Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NFederico Manzan <f.manzan@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The control-message timeout is specified in milliseconds and should not depend on HZ. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The control and bulk-message timeouts are specified in milliseconds and should not depend on HZ. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The bulk-message timeout is specified in milliseconds and should not depend on HZ. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The control-message timeout is specified in milliseconds and should not depend on HZ. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Fix regression introduced by commit 0eafe4de ("USB: serial: mos7840: add support for MCS7810 devices") which used stack-allocated buffers for control messages. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
The read_mos_reg function is called with stack-allocated buffers, which must not be used for control messages. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
Fix regression introduced by commit 214916f2 ("USB: visor: reimplement using generic framework") which broke initialisation of Treo/Kyocera devices that re-mapped bulk-in endpoints. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Johan Hovold 提交于
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. Cc: stable@vger.kernel.org Signed-off-by: NJohan Hovold <jhovold@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch reverts commit 3e619d04 (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: NAlan Stern <stern@rowland.harvard.edu> CC: Joseph Salisbury <joseph.salisbury@canonical.com> CC: Tim Richardson <tim@tim-richardson.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Virupax Sadashivpetimath 提交于
Since highmem PIO URB handling was introduced in: 8e8a5516 usb: musb: host: Handle highmem in PIO mode when a URB is being handled it may happen that the static use_sg flag was set by a previous URB with buffer in highmem. This leads to error in handling the present URB. Fix this by making the use_sg flag URB specific. Cc: stable <stable@vger.kernel.org> # 3.7+ Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NVirupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com> Signed-off-by: NFabio Baltieri <fabio.baltieri@linaro.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 George Cherian 提交于
we never allocate a TRB pool for physical endpoints 0 and 1 so trying to free it (a invalid TRB pool pointer) will lead us in a warning while removing dwc3.ko module. In order to fix the situation, all we have to do is skip dwc3_free_trb_pool() for physical endpoints 0 and 1 just as we while deleting endpoints from the endpoints list. Cc: stable@vger.kernel.org Signed-off-by: NGeorge Cherian <george.cherian@ti.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Peter Chen 提交于
If the glue layer is removed first (core layer later), it deletes the phy device first, then the core device. But at core's removal, it still uses PHY's resources, it may cause kernel's oops. It is much like the problem Paul Zimmerman reported at: http://marc.info/?l=linux-usb&m=136547502011472&w=2. Besides, it is reasonable the PHY is deleted at last as the controller is the PHY's user. Signed-off-by: NPeter Chen <peter.chen@freescale.com> Cc: <stable@vger.kernel.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
由 Peter Chen 提交于
If the glue layer is removed first (core layer later), it deletes the phy device first, then the core device. But at core's removal, it still uses PHY's resources, it may cause kernel's oops. It is much like the problem Paul Zimmerman reported at: http://marc.info/?l=linux-usb&m=136547502011472&w=2. Besides, it is reasonable the PHY is deleted at last as the controller is the PHY's user. Signed-off-by: NPeter Chen <peter.chen@freescale.com> Cc: <stable@vger.kernel.org> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 25 5月, 2013 16 次提交
-
-
由 Tomasz Figa 提交于
Currently the driver can crash with a NULL pointer dereference if no pdata is provided, despite of successful registration of the MFD part. This patch fixes the problem by adding a NULL check before dereferencing the pdata pointer. Signed-off-by: NTomasz Figa <t.figa@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Sachin Kamat <sachin.kamat@linaro.org> Reviewed-by: NJingoo Han <jg1.han@samsung.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Kosina 提交于
Commit 902c098a ("random: use lockless techniques in the interrupt path") turned IRQ path from being spinlock protected into lockless cmpxchg-retry update. That commit removed r->lock serialization between crediting entropy bits from IRQ context and accounting when extracting entropy on userspace read path, but didn't turn the r->entropy_count reads/updates in account() to use cmpxchg as well. It has been observed, that under certain circumstances this leads to read() on /dev/urandom to return 0 (EOF), as r->entropy_count gets corrupted and becomes negative, which in turn results in propagating 0 all the way from account() to the actual read() call. Convert the accounting code to be the proper lockless counterpart of what has been partially done by 902c098a. Signed-off-by: NJiri Kosina <jkosina@suse.cz> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Greg KH <greg@kroah.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jarod Wilson 提交于
Commit ec8f02da ("random: prime last_data value per fips requirements") added priming of last_data per fips requirements. Unfortuantely, it did so in a way that can lead to multiple threads all incrementing nbytes, but only one actually doing anything with the extra data, which leads to some fun random corruption and panics. The fix is to simply do everything needed to prime last_data in a single shot, so there's no window for multiple cpus to increment nbytes -- in fact, we won't even increment or decrement nbytes anymore, we'll just extract the needed EXTRACT_SIZE one time per pool and then carry on with the normal routine. All these changes have been tested across multiple hosts and architectures where panics were previously encoutered. The code changes are are strictly limited to areas only touched when when booted in fips mode. This change should also go into 3.8-stable, to make the myriads of fips users on 3.8.x happy. Signed-off-by: NJarod Wilson <jarod@redhat.com> Tested-by: NJan Stancek <jstancek@redhat.com> Tested-by: NJan Stodola <jstodola@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: NNeil Horman <nhorman@tuxdriver.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Matt Mackall <mpm@selenic.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Brian Behlendorf 提交于
The index on the page must be set before it is inserted in the radix tree. Otherwise there is a small race which can occur during lookup where the page can be found with the incorrect index. This will trigger the BUG_ON() in brd_lookup_page(). Signed-off-by: NBrian Behlendorf <behlendorf1@llnl.gov> Reported-by: NChris Wedgwood <cw@f00f.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Geert Uytterhoeven 提交于
If NO_DMA=y: drivers/built-in.o: In function `goldfish_fb_remove': drivers/video/goldfishfb.c:301: undefined reference to `dma_free_coherent' drivers/built-in.o: In function `goldfish_fb_probe': drivers/video/goldfishfb.c:247: undefined reference to `dma_alloc_coherent' drivers/video/goldfishfb.c:280: undefined reference to `dma_free_coherent' Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Lars-Peter Clausen 提交于
free_irq() expects the same pointer that was passed to request_irq(), otherwise the IRQ is not freed. The issue was found using the following coccinelle script: <smpl> @r1@ type T; T devid; @@ request_irq(..., devid) @r2@ type r1.T; T devid; position p; @@ free_irq@p(..., devid) @@ position p != r2.p; @@ *free_irq@p(...) </smpl> Signed-off-by: NLars-Peter Clausen <lars@metafoo.de> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Christian Gmeiner 提交于
During the development of this driver an in-house register documentation was used. The last week some integration tests were done and this problem was found. It turned out that the released register documentation is wrong. The fix is very simple: shift all masks by one. Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Cc: Bryan Wu <cooloney@gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alexandre Bounine 提交于
Fix bug in MSI interrupt handling which causes loss of event notifications. Typical indication of lost MSI interrupts are stalled message and doorbell transfers between RapidIO endpoints. To avoid loss of MSI interrupts all interrupts from the device must be disabled on entering the interrupt handler routine and re-enabled when exiting it. Re-enabling device interrupts will trigger new MSI message(s) if Tsi721 registered new events since entering interrupt handler routine. This patch is applicable to kernel versions starting from v3.2. Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Stephen Warren 提交于
A simple frame-buffer describes a raw memory region that may be rendered to, with the assumption that the display hardware has already been set up to scan out from that buffer. This is useful in cases where a bootloader exists and has set up the display hardware, but a Linux driver doesn't yet exist for the display hardware. Examples use-cases include: * The built-in LCD panels on the Samsung ARM chromebook, and Tegra devices, and likely many other ARM or embedded systems. These cannot yet be supported using a full graphics driver, since the panel control should be provided by the CDF (Common Display Framework), which has been stuck in design/review for quite some time. One could support these panels using custom SoC-specific code, but there is a desire to use common infra-structure rather than having each SoC vendor invent their own code, hence the desire to wait for CDF. * Hardware for which a full graphics driver is not yet available, and the path to obtain one upstream isn't yet clear. For example, the Raspberry Pi. * Any hardware in early stages of upstreaming, before a full graphics driver has been tackled. This driver can provide a graphical boot console (even full X support) much earlier in the upstreaming process, thus making new SoC or board support more generally useful earlier. [akpm@linux-foundation.org: make simplefb_formats[] static] Signed-off-by: NStephen Warren <swarren@wwwdotorg.org> Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: NOlof Johansson <olof@lixom.net> Cc: Rob Clark <robclark@gmail.com> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Tomasz Figa <tomasz.figa@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alexandre Bounine 提交于
Add RapidIO enumeration/discovery start from user space. User space start allows to defer RapidIO fabric scan until the moment when all participating endpoints are initialized avoiding mandatory synchronized start of all endpoints (which may be challenging in systems with large number of RapidIO endpoints). Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Li Yang <leoli@freescale.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Andre van Herk <andre.van.herk@Prodrive.nl> Cc: Micha Nelissen <micha.nelissen@Prodrive.nl> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alexandre Bounine 提交于
Systems that use RapidIO fabric may need to implement their own enumeration and discovery methods which are better suitable for needs of a target application. The following set of patches is intended to simplify process of introduction of new RapidIO fabric enumeration/discovery methods. The first patch offers ability to add new RapidIO enumeration/discovery methods using kernel configuration options. This new configuration option mechanism allows to select statically linked or modular enumeration/discovery method(s) from the list of existing methods or use external module(s). This patch also updates the currently existing enumeration/discovery code to be used as a statically linked or modular method. The corresponding configuration option is named "Basic enumeration/discovery" method. This is the only one configuration option available today but new methods are expected to be introduced after adoption of provided patches. The second patch address a long time complaint of RapidIO subsystem users regarding fabric enumeration/discovery start sequence. Existing implementation offers only a boot-time enumeration/discovery start which requires synchronized boot of all endpoints in RapidIO network. While it works for small closed configurations with limited number of endpoints, using this approach in systems with large number of endpoints is quite challenging. To eliminate requirement for synchronized start the second patch introduces RapidIO enumeration/discovery start from user space. For compatibility with the existing RapidIO subsystem implementation, automatic boot time enumeration/discovery start can be configured in by specifying "rio-scan.scan=1" command line parameter if statically linked basic enumeration method is selected. This patch: Rework to implement RapidIO enumeration/discovery method selection combined with ability to use enumeration/discovery as a kernel module. This patch adds ability to introduce new RapidIO enumeration/discovery methods using kernel configuration options. Configuration option mechanism allows to select statically linked or modular enumeration/discovery method from the list of existing methods or use external modules. If a modular enumeration/discovery is selected each RapidIO mport device can have its own method attached to it. The existing enumeration/discovery code was updated to be used as statically linked or modular method. This configuration option is named "Basic enumeration/discovery" method. Several common routines have been moved from rio-scan.c to make them available to other enumeration methods and reduce number of exported symbols. Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Li Yang <leoli@freescale.com> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: Andre van Herk <andre.van.herk@Prodrive.nl> Cc: Micha Nelissen <micha.nelissen@Prodrive.nl> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Gernot Vormayr 提交于
If the port number is missing from the device-tree the device gets named xs` instead of xsa. This fixes the check for missing ids. Tested on ml507 board. Signed-off-by: NGernot Vormayr <gvormayr@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Grant Likely <grant.likely@linaro.org> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Sarah Sharp 提交于
Some xHCI hosts contain a "redriver" from TI that silently drops port status connect changes if the port slips into Compliance Mode. If the port slips into compliance mode while the host is in D0, there will not be a port status change event. If the port slips into compliance mode while the host is in D3, the host will not send a PME. This includes when the system is suspended (S3) or hibernated (S4). If this happens when the system is in S3/S4, there is nothing software can do. Other port status change events that would normally cause the host to wake the system from S3/S4 may also be lost. This includes remote wakeup, disconnects and connects on other ports, and overrcurrent events. A decision was made to _NOT_ disable system suspend/hibernate on these systems, since users are unlikely to enable wakeup from S3/S4 for the xHCI host. Software can deal with this issue when the system is in S0. A work around was put in to poll the port status registers for Compliance Mode. The xHCI driver will continue to poll the registers while the host is runtime suspended. Unfortunately, that means we can't allow the PCI device to go into D3cold, because power will be removed from the host, and the config space will read as all Fs. Disable D3cold in the xHCI PCI runtime suspend function. This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a2 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Huang Ying <ying.huang@intel.com> Cc: stable@vger.kernel.org
-
由 Tony Camuso 提交于
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 71c731a2 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: NTony Camuso <tcamuso@redhat.com> Tested-by: NTony Camuso <tcamuso@redhat.com> Acked-by: NDon Zickus <dzickus@redhat.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
由 Peter Huewe 提交于
Removing some boilerplate by using module_pci_driver instead of calling register and unregister in the otherwise empty init/exit functions. Signed-off-by: NPeter Huewe <peterhuewe@gmx.de> Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Vladimir Murzin 提交于
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 839c817c "xhci: Store information about roothubs and TTs." Reported-by: NSergey Dyasly <dserrg@gmail.com> Tested-by: NSergey Dyasly <dserrg@gmail.com> Signed-off-by: NVladimir Murzin <murzin.v@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-