aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/host
Commit message (Collapse)AuthorAgeFilesLines
...
* usb: ehci-mxc: check for pdata before dereferencingDaniel Mack2013-10-261-1/+1
| | | | | | | | | | | | | | | | commit f375fc520d4df0cd9fcb570f33c103c6c0311f9e upstream. Commit 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based boards") introduced code that could potentially lead to a NULL pointer dereference on driver removal. Fix this by checking for the value of pdata before dereferencing it. Signed-off-by: Daniel Mack <zonque@gmail.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: fix null pointer dereference on ring_doorbell_for_active_ringsOleksij Rempel2013-08-021-1/+1
| | | | | | | | | | | | | | | | | commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream. in some cases where device is attched to xhci port and do not responding, for example ath9k_htc with stalled firmware, kernel will crash on ring_doorbell_for_active_rings. This patch check if pointer exist before it is used. This patch should be backported to kernels as old as 2.6.35, that contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci: Correct assumptions about number of rings per endpoint" Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0George Cherian2013-08-022-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream. Xhci controllers with hci_version > 0.96 gives spurious success events on short packet completion. During webcam capture the "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. The same application works fine with synopsis controllers hci_version 0.96. The same issue is seen with Intel Pantherpoint xhci controller. So enabling this quirk in xhci_gen_setup if controller verion is greater than 0.96. For xhci-pci move the quirk to much generic place xhci_gen_setup. Note from Sarah: The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet occurred, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD is not completed until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. It's on my long-term to-do list to fix this race condition, but it is a much more involved patch that will probably be too big for stable. This patch is needed for stable to avoid serious log spam. This patch should be backported to kernels as old as 3.0, that contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci: Ignore spurious successful event." The patch will have to be modified for kernels older than 3.2, since that kernel added the xhci_gen_setup function for xhci platform devices. The correct conflict resolution for kernels older than 3.2 is to set XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts. Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Avoid NULL pointer deref when host dies.Sarah Sharp2013-08-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream. When the host controller fails to respond to an Enable Slot command, and the host fails to respond to the register write to abort the command ring, the xHCI driver will assume the host is dead, and call usb_hc_died(). The USB device's slot_id is still set to zero, and the pointer stored at xhci->devs[0] will always be NULL. The call to xhci_check_args in xhci_free_dev should have caught the NULL virt_dev pointer. However, xhci_free_dev is designed to free the xhci_virt_device structures, even if the host is dead, so that we don't leak kernel memory. xhci_free_dev checks the return value from the generic xhci_check_args function. If the return value is -ENODEV, it carries on trying to free the virtual device. The issue is that xhci_check_args looks at the host controller state before it looks at the xhci_virt_device pointer. It will return -ENIVAL because the host is dead, and xhci_free_dev will ignore the return value, and happily dereference the NULL xhci_virt_device pointer. The fix is to make sure that xhci_check_args checks the xhci_virt_device pointer before it checks the host state. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for further details. This patch doesn't solve the underlying issue, but will ensure we don't see any more NULL pointer dereferences because of the issue. This patch should be backported to kernels as old as 3.1, that contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't submit commands or URBs to halted hosts." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Vincent Thiele <vincentthiele@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: check for failed dma pool allocationMathias Nyman2013-07-271-0/+4
| | | | | | | | | | | | | | | | | commit 025f880cb2e4d7218d0422d4b07bea1a68959c38 upstream. Fail and free the container context in case dma_pool_alloc() can't allocate the raw context data part of it This patch should be backported to kernels as old as 2.6.31, that contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci: Support for 64-byte contexts". Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: revert periodic scheduling bugfixAlan Stern2013-06-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stern@rowland.harvard.edu> CC: Joseph Salisbury <joseph.salisbury@canonical.com> CC: Tim Richardson <tim@tim-richardson.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci - correct comp_mode_recovery_timer on return from hibernateTony Camuso2013-06-191-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tcamuso@redhat.com> Tested-by: Tony Camuso <tcamuso@redhat.com> Acked-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: fix list access before initVladimir Murzin2013-06-191-0/+4
| | | | | | | | | | | | | | | | | | | | 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 <dserrg@gmail.com> Tested-by: Sergey Dyasly <dserrg@gmail.com> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci-mem: init list heads at the beginning of initSergio Aguirre2013-06-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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 <sergio.a.aguirre.rodriguez@intel.com> Acked-by: David Cohen <david.a.cohen@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Don't warn on empty ring for suspended devices.Sarah Sharp2013-05-301-8/+15
| | | | | | | | | | | | | | | | commit a83d6755814e4614ba77e15d82796af0f695c6b8 upstream. When a device attached to the roothub is suspended, the endpoint rings are stopped. The host may generate a completion event with the completion code set to 'Stopped' or 'Stopped Invalid' when the ring is halted. The current xHCI code prints a warning in that case, which can be really annoying if the USB device is coming into and out of suspend. Remove the unnecessary warning. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: UHCI: fix for suspend of virtual HP controllerAlan Stern2013-05-301-1/+2
| | | | | | | | | | | | | | | | | | | commit 997ff893603c6455da4c5e26ba1d0f81adfecdfc upstream. HP's virtual UHCI host controller takes a long time to suspend (several hundred microseconds), even when no devices are attached. This provokes a warning message from uhci-hcd in the auto-stop case. To prevent this from happening, this patch adds a test to avoid performing an auto-stop when the wait_for_hp quirk flag is set. The controller will still suspend through the normal runtime PM mechanism. And since that pathway includes a 1-ms delay, the slowness of the virtual hardware won't matter. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: ZhenHua <zhen-hual@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: xHCI: override bogus bulk wMaxPacketSize valuesAlan Stern2013-05-301-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | commit e4f47e3675e6f1f40906b785b934ce963e9f2eb3 upstream. This patch shortens the logic in xhci_endpoint_init() by moving common calculations involving max_packet and max_burst outside the switch statement, rather than repeating the same code in multiple case-specific statements. It also replaces two usages of max_packet which were clearly intended to be max_burst all along. More importantly, it compensates for a common bug in high-speed bulk endpoint descriptors. In many devices there is a bulk endpoint having a wMaxPacketSize value smaller than 512, which is forbidden by the USB spec. Some xHCI controllers can't handle this and refuse to accept the endpoint. This patch changes the max_packet value to 512, which allows the controller to use the endpoint properly. In practice the bogus maxpacket size doesn't matter, because none of the transfers sent via these endpoints are longer than the maxpacket value anyway. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: "Aurélien Leblond" <blablack@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: xhci: Fix TRB transfer length macro used for Event TRB.Vivek Gautam2013-04-102-12/+16
| | | | | | | | | | | | | | | | | | commit 1c11a172cb30492f5f6a82c6e118fdcd9946c34f upstream. Use proper macro while extracting TRB transfer length from Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23) for the same, and use it instead of TRB_LEN (bits 0:16) in case of event TRBs. This patch should be backported to kernels as old as 2.6.31, that contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci: Bulk transfer support". This patch will have issues applying to older kernels. Signed-off-by: Vivek gautam <gautam.vivek@samsung.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: xhci - fix bit definitions for IMAN registerDmitry Torokhov2013-03-271-2/+2
| | | | | | | | | | | | | | | | | | | | commit f8264340e694604863255cc0276491d17c402390 upstream. According to XHCI specification (5.5.2.1) the IP is bit 0 and IE is bit 1 of IMAN register. Previously their definitions were reversed. Even though there are no ill effects being observed from the swapped definitions (because IMAN_IP is RW1C and in legacy PCI case we come in with it already set to 1 so it was clearing itself even though we were setting IMAN_IE instead of IMAN_IP), we should still correct the values. This patch should be backported to kernels as old as 2.6.36, that contain the commit 4e833c0b87a30798e67f06120cecebef6ee9644c "xhci: don't re-enable IE constantly". Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: xhci: correctly enable interruptsHannes Reinecke2013-03-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb upstream. xhci has its own interrupt enabling routine, which will try to use MSI-X/MSI if present. So the usb core shouldn't try to enable legacy interrupts; on some machines the xhci legacy IRQ setting is invalid. v3: Be careful to not break XHCI_BROKEN_MSI workaround (by trenn) Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Oliver Neukum <oneukum@suse.de> Cc: Thomas Renninger <trenn@suse.de> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Frederik Himpe <fhimpe@vub.ac.be> Cc: David Haerdeman <david@hardeman.nu> Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reviewed-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: ehci-omap: Fix autoloading of moduleRoger Quadros2013-03-061-1/+1
| | | | | | | | | | | | | commit 04753523266629b1cd0518091da1658755787198 upstream. The module alias should be "ehci-omap" and not "omap-ehci" to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by: Roger Quadros <rogerq@ti.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: EHCI: fix bug in scheduling periodic split transfersAlan Stern2013-02-201-1/+1
| | | | | | | | | | | | | | | | | | | commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d upstream. This patch (as1654) fixes a very old bug in ehci-hcd, connected with scheduling of periodic split transfers. The calculations for full/low-speed bus usage are all carried out after the correction for bit-stuffing has been applied, but the values in the max_tt_usecs array assume it hasn't been. The array should allow for allocation of up to 90% of the bus capacity, which is 900 us, not 780 us. The symptom caused by this bug is that any isochronous transfer to a full-speed device with a maxpacket size larger than about 980 bytes is always rejected with a -ENOSPC error. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: Prevent dead ports when xhci is not enabledDavid Moore2013-02-201-0/+1
| | | | | | | | | | | | | | | | | commit 58b2939b4d5a030eaec469d29812ab8477ee7e76 upstream. When the xHCI driver is not available, actively switch the ports to EHCI mode since some BIOSes leave them in xHCI mode where they would otherwise appear dead. This was discovered on a Dell Optiplex 7010, but it's possible other systems could be affected. This should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: David Moore <david.moore@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: XHCI: fix memory leak of URB-private dataAlan Stern2013-02-201-0/+2
| | | | | | | | | | | | | | | | | | commit 48c3375c5f69b1c2ef3d1051a0009cb9bce0ce24 upstream. This patch (as1640) fixes a memory leak in xhci-hcd. The urb_priv data structure isn't always deallocated in the handle_tx_event() routine for non-control transfers. The patch adds a kfree() call so that all paths end up freeing the memory properly. This patch should be backported to kernels as old as 2.6.36, that contain the commit 8e51adccd4c4b9ffcd509d7f2afce0a906139f75 "USB: xHCI: Introduce urb_priv structure" Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-and-tested-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Fix TD size for isochronous URBs.Sarah Sharp2013-02-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit f18f8ed2a9adc41c2d9294b85b6af115829d2af1 upstream. To calculate the TD size for a particular TRB in an isoc TD, we need know the endpoint's max packet size. Isochronous endpoints also encode the number of additional service opportunities in their wMaxPacketSize field. The TD size calculation did not mask off those bits before using the field. This resulted in incorrect TD size information for isochronous TRBs when an URB frame buffer crossed a 64KB boundary. For example: - an isoc endpoint has 2 additional service opportunites and a max packet size of 1020 bytes - a frame transfer buffer contains 3060 bytes - one frame buffer crosses a 64KB boundary, and must be split into one 1276 byte TRB, and one 1784 byte TRB. The TD size is is the number of packets that remain to be transferred for a TD after processing all the max packet sized packets in the current TRB and all previous TRBs. For this TD, the number of packets to be transferred is (3060 / 1020), or 3. The first TRB contains 1276 bytes, which means it contains one full packet, and a 256 byte remainder. After processing all the max packet-sized packets in the first TRB, the host will have 2 packets left to transfer. The old code would calculate the TD size for the first TRB as: total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize) total packet count - (first TRB length / endpoint wMaxPacketSize) The math should have been: total packet count = DIV_ROUND_UP (3060 / 1020) = 3 3 - (1276 / 1020) = 2 Since the old code didn't mask off the additional service interval bits from the wMaxPacketSize field, the math ended up as total packet count = DIV_ROUND_UP (3060 / 5116) = 1 1 - (1276 / 5116) = 1 Fix this by masking off the number of additional service opportunities in the wMaxPacketSize field. This patch should be backported to stable kernels as old as 3.0, that contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD size field format." It may not apply well to kernels older than 3.2 because of commit 29cc88979a8818cd8c5019426e945aed118b400e "USB: use usb_endpoint_maxp() instead of le16_to_cpu()". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Fix isoc TD encoding.Sarah Sharp2013-02-201-1/+3
| | | | | | | | | | | | | | | | commit 760973d2a74b93eb1697981f7448f0e62767cfc4 upstream. An isochronous TD is comprised of one isochronous TRB chained to zero or more normal TRBs. Only the isoc TRB has the TBC and TLBPC fields. The normal TRBs must set those fields to zeroes. The code was setting the TBC and TLBPC fields for both isoc and normal TRBs. Fix this. This should be backported to stable kernels as old as 3.0, that contain the commit b61d378f2da41c748aba6ca19d77e1e1c02bcea5 " xhci 1.0: Set transfer burst last packet count field." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: UHCI: fix IRQ race during initializationAlan Stern2013-02-061-6/+9
| | | | | | | | | | | | | | | | | | | commit 0f815a0a700bc10547449bde6c106051a035a1b9 upstream. This patch (as1644) fixes a race that occurs during startup in uhci-hcd. If the IRQ line is shared with other devices, it's possible for the handler routine to be called before the data structures are fully initialized. The problem is fixed by adding a check to the IRQ handler routine. If the initialization hasn't finished yet, the routine will return immediately. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Don Zickus <dzickus@redhat.com> Tested-by: "Huang, Adrian (ISS Linux TW)" <adrian.huang@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Avoid "dead ports", add roothub port polling.Sarah Sharp2013-02-063-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit c52804a472649b2e5005342308739434cbd51119 upstream. The USB core hub thread (khubd) is designed with external USB hubs in mind. It expects that if a port status change bit is set, the hub will continue to send a notification through the hub status data transfer. Basically, it expects hub notifications to be level-triggered. The xHCI host controller is designed to be edge-triggered on the logical 'OR' of all the port status change bits. When all port status change bits are clear, and a new change bit is set, the xHC will generate a Port Status Change Event. If another change bit is set in the same port status register before the first bit is cleared, it will not send another event. This means that the hub code may lose port status changes because of race conditions between clearing change bits. The user sees this as a "dead port" that doesn't react to device connects. The fix is to turn on port polling whenever a new change bit is set. Once the USB core issues a hub status request that shows that no change bits are set in any USB ports, turn off port polling. We can't allow the USB core to poll the roothub for port events during host suspend because if the PCI host is in D3cold, the port registers will be all f's. Instead, stop the port polling timer, and unconditionally restart it when the host resumes. If there are no port change bits set after the resume, the first call to hub_status_data will disable polling. This patch should be backported to stable kernels with the first xHCI support, 2.6.31 and newer, that include the commit 0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support." There will be merge conflicts because the check for HC_STATE_SUSPENDED was moved into xhci_suspend in 3.8. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: Allow USB 3.0 ports to be disabled.Sarah Sharp2013-02-061-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 41e7e056cdc662f704fa9262e5c6e213b4ab45dd upstream. If hot and warm reset fails, or a port remains in the Compliance Mode, the USB core needs to be able to disable a USB 3.0 port. Unlike USB 2.0 ports, once the port is placed into the Disabled link state, it will not report any new device connects. To get device connect notifications, we need to put the link into the Disabled state, and then the RxDetect state. The xHCI driver needs to atomically clear all change bits on USB 3.0 port disable, so that we get Port Status Change Events for future port changes. We could technically do this in the USB core instead of in the xHCI roothub code, since the port state machine can't advance out of the disabled state until we set the link state to RxDetect. However, external USB 3.0 hubs don't need this code. They are level-triggered, not edge-triggered like xHCI, so they will continue to send interrupt events when any change bit is set. Therefore it doesn't make sense to put this code in the USB core. This patch is part of a series to fix several reports of infinite loops on device enumeration failure. This includes John, when he boots with a USB 3.0 device (Roseweil eusb3 enclosure) attached to his NEC 0.96 host controller. The fix requires warm reset support, so it does not make sense to backport this patch to stable kernels without warm reset support. This patch should be backported to kernels as old as 3.2, contain the commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm reset logic" Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: John Covici <covici@ccs.covici.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Handle HS bulk/ctrl endpoints that don't NAK.Sarah Sharp2013-02-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit 55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream. A high speed control or bulk endpoint may have bInterval set to zero, which means it does not NAK. If bInterval is non-zero, it means the endpoint NAKs at a rate of 2^(bInterval - 1). The xHCI code to compute the NAK interval does not handle the special case of zero properly. The current code unconditionally subtracts one from bInterval and uses it as an exponent. This causes a very large bInterval to be used, and warning messages like these will be printed: usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes This may cause the xHCI host hardware to reject the Configure Endpoint command, which means the HS device will be unusable under xHCI ports. This patch should be backported to kernels as old as 2.6.31, that contain commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()". Reported-by: Vincent Pelletier <plr.vincent@gmail.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Add Lynx Point LP to list of Intel switchable hostsRussell Webb2013-01-032-2/+5
| | | | | | | | | | | | | | | commit bb1e5dd7113d2fd178d3af9aca8f480ae0468edf upstream. Like Lynx Point, Lynx Point LP is also switchable. See 1c12443ab8eba71a658fae4572147e56d1f84f66 for more details. This patch should be backported to stable kernels as old as 3.0, that contain commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Russell Webb <russell.webb@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: OHCI: workaround for hardware bug: retired TDs not added to the Done QueueAlan Stern2013-01-031-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | commit 50ce5c0683aa83eb161624ea89daa5a9eee0c2ce upstream. This patch (as1636) is a partial workaround for a hardware bug affecting OHCI controllers by NVIDIA at least, maybe others too. When the controller retires a Transfer Descriptor, it is supposed to add the TD onto the Done Queue. But sometimes this doesn't happen, with the result that ohci-hcd never realizes the corresponding transfer has finished. Symptoms can vary; a typical result is that USB audio stops working after a while. The patch works around the problem by recognizing that TDs are always processed in order. Therefore, if a later TD is found on the Done Queue than all the earlier TDs for the same endpoint must be finished as well. Unfortunately this won't solve the problem in cases where the missing TD is the last one in the endpoint's queue. A complete fix would require a signficant amount of change to the driver. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: host: xhci: Stricter conditional for Z1 system models for Compliance ↵Alexis R. Cortes2013-01-031-1/+1
| | | | | | | | | | | | | | | | | | Mode Patch commit b0e4e606ff6ff26da0f60826e75577b56ba4e463 upstream. This minor patch creates a more stricter conditional for the Z1 sytems for applying the Compliance Mode Patch, this to avoid the quirk to be applied to models that contain a "Z1" in their dmi product string but are different from Z1 systems. This patch should be backported to stable kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Extend Fresco Logic MSI quirk.Sarah Sharp2013-01-031-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 upstream. Ali reports that plugging a device into the Fresco Logic xHCI host with PCI device ID 1400 produces an IRQ error: do_IRQ: 3.176 No irq handler for vector (irq -1) Other early Fresco Logic host revisions don't support MSI, even though their PCI config space claims they do. Extend the quirk to disabling MSI to this chipset revision. Also enable the short transfer quirk, since it's likely this revision also has that quirk, and it should be harmless to enable. 04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI]) Subsystem: 1d5c:1000 Physical Slot: 3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 51 Region 0: Memory at d4600000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000feeff00c Data: 41b1 Capabilities: [80] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <2us, L1 <32us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: xhci_hcd This patch should be backported to stable kernels as old as 2.6.36, that contain the commit f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some Fresco Logic hosts." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: A Sh <smr.ash1991@gmail.com> Tested-by: A Sh <smr.ash1991@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: fix null-pointer dereference when destroying half-built segment ringsJulius Werner2013-01-031-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 68e5254adb88bede68285f11fb442a4d34fb550c upstream. xhci_alloc_segments_for_ring() builds a list of xhci_segments and links the tail to head at the end (forming a ring). When it bails out for OOM reasons half-way through, it tries to destroy its half-built list with xhci_free_segments_for_ring(), even though it is not a ring yet. This causes a null-pointer dereference upon hitting the last element. Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes the output parameters to be valid upon this kind of OOM failure, and calls xhci_ring_free() on them. Since the (incomplete) list/ring should already be destroyed in that case, this would lead to a use after free. This patch fixes those issues by having xhci_alloc_segments_for_ring() destroy its half-built, non-circular list manually and destroying the invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree(). This patch should be backported to kernels as old as 2.6.31, that contains the commit 0ebbab37422315a5d0cb29792271085bafdf38c0 "USB: xhci: Ring allocation and initialization." A separate patch will need to be developed for kernels older than 3.4, since the ring allocation code was refactored in that kernel. Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> [bwh: Backported to 3.2: - Adjust context - Since segment allocation is done directly in xhci_ring_alloc(), walk the list starting from ring->first_seg when freeing] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xHCI: Fix TD Size calculation on 1.0 hosts.Sarah Sharp2013-01-031-13/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 4525c0a10dff7ad3669763c28016c7daffc3900e upstream. The xHCI 1.0 specification made a change to the TD Size field in TRBs. The value is now the number of packets that remain to be sent in the TD, not including this TRB. The TD Size value for the last TRB in a TD must always be zero. The xHCI function xhci_v1_0_td_remainder() attempts to calculate this, but it gets it wrong. First, it erroneously reuses the old xhci_td_remainder function, which will right shift the value by 10. The xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10. Second, it does not set the TD size for the last TRB in a TD to zero. Third, it uses roundup instead of DIV_ROUND_UP. The total packet count is supposed to be the total number of bytes in this TD, divided by the max packet size, rounded up. DIV_ROUND_UP is the right function to use in that case. With the old code, a TD on an endpoint with max packet size 1024 would be set up like so: TRB 1, TRB length = 600 bytes, TD size = 0 TRB 1, TRB length = 200 bytes, TD size = 0 TRB 1, TRB length = 100 bytes, TD size = 0 With the new code, the TD would be set up like this: TRB 1, TRB length = 600 bytes, TD size = 1 TRB 1, TRB length = 200 bytes, TD size = 1 TRB 1, TRB length = 100 bytes, TD size = 0 This commit should be backported to kernels as old as 3.0, that contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD size field format." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com> Reported-by: Shimmer Huang <shimmering.h@gmail.com> Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com> Tested-by: Shimmer Huang <shimmering.h@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Fix conditional check in bandwidth calculation.Sarah Sharp2013-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 392a07ae3316f2b90b39ce41e66d6f6b5c95de90 upstream. David reports that at drivers/usb/host/xhci.c:2257: static bool xhci_is_sync_in_ep(unsigned int ep_type) { return (ep_type == ISOC_IN_EP || ep_type != INT_IN_EP); } The static analyser cppcheck says [linux-3.7-rc2/drivers/usb/host/xhci.c:2257]: (style) Redundant condition: If ep_type == 5, the comparison ep_type != 7 is always true. Maybe the original programmer intention was something like static bool xhci_is_sync_in_ep(unsigned int ep_type) { return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP); } Fix this. This patch should be backported to stable kernels as old as 3.2, that contain the commit 2b69899934c63b7b9432568584fb4c4a2924f40c "xhci: USB 3.0 BW checking." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: David Binderman <dcb314@hotmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* USB: EHCI: bugfix: urb->hcpriv should not be NULLAlan Stern2013-01-032-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 2656a9abcf1ec8dd5fee6a75d6997a0f2fa0094e upstream. This patch (as1632b) fixes a bug in ehci-hcd. The USB core uses urb->hcpriv to determine whether or not an URB is active; host controller drivers are supposed to set this pointer to a non-NULL value when an URB is queued. However ehci-hcd sets it to NULL for isochronous URBs, which defeats the check in usbcore. In itself this isn't a big deal. But people have recently found that certain sequences of actions will cause the snd-usb-audio driver to reuse URBs without waiting for them to complete. In the absence of proper checking by usbcore, the URBs get added to their endpoint list twice. This leads to list corruption and a system freeze. The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for isochronous URBs. Improving robustness always helps. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Artem S. Tashkinov <t.artem@lycos.com> Reported-by: Christof Meerwald <cmeerw@cmeerw.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: - Adjust context - Also use usb_pipetype() to work out whether we should call qh_put()] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Remove scary warnings about transfer issues.Sarah Sharp2012-12-061-4/+3
| | | | | | | | | | | commit 2a9227a5eeaeb3f91e3a72ceea4fa59016ca5d20 upstream. Getting a short packet or a babble error is usually a recoverable error, so stop scaring users with warnings in dmesg when xHCI debugging is turned off. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Remove warnings about MSI and MSI-X capabilities.Sarah Sharp2012-12-061-4/+4
| | | | | | | | | | | | | | | | | commit 3b9783b277e66731891ab42eeaacebbdcdd6e629 upstream. xHCI host controllers may not be capable of MSI, but they should be able to be used in legacy PCI interrupt mode. Similarly, some xHCI host controllers will have MSI support but not MSI-X support. Lower the dmesg log level from an error to debug. The message won't appear unless CONFIG_USB_XHCI_HCD_DEBUGGING is turned on. If we need to find out whether the device can support MSI or MSI-X and it's not being enabled by the driver, it's easy to ask the user to run lspci. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Fix potential NULL ptr deref in command cancellation.Sarah Sharp2012-10-301-0/+11
| | | | | | | | | | | | | | | | | commit 43a09f7fb01fa1e091416a2aa49b6c666458c1ee upstream. The command cancellation code doesn't check whether find_trb_seg() couldn't find the segment that contains the TRB to be canceled. This could cause a NULL pointer deference later in the function when next_trb is called. It's unlikely to happen unless something is wrong with the command ring pointers, so add some debugging in case it happens. This patch should be backported to stable kernels as old as 3.0, that contain the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI: handle command after aborting the command ring". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* ehci: Add yet-another Lucid nohandoff pci quirkAnisse Astier2012-10-301-0/+7
| | | | | | | | | | commit 8daf8b6086f9d575200cd0aa3797e26137255609 upstream. Board name changed on another shipping Lucid tablet. Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* ehci: fix Lucid nohandoff pci quirk to be more generic with BIOS versionsAnisse Astier2012-10-301-1/+1
| | | | | | | | | | | commit c323dc023b9501e5d09582ec7efd1d40a9001d99 upstream. BIOS vendors keep changing the BIOS versions. Only match the beginning of the string to match all Lucid tablets with board name M11JB. Signed-off-by: Anisse Astier <anisse@astier.eu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: host: xhci: New system added for Compliance Mode Patch on SN65LVPE502CPAlexis R. Cortes2012-10-301-1/+2
| | | | | | | | | | | | | | | commit 470809741a28c3092279f4e1f3f432e534d46068 upstream. This minor change adds a new system to which the "Fix Compliance Mode on SN65LVPE502CP Hardware" patch has to be applied also. System added: Vendor: Hewlett-Packard. System Model: Z1 Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xHCI: handle command after aborting the command ringElric Fu2012-10-171-6/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d upstream. According to xHCI spec section 4.6.1.1 and section 4.6.1.2, after aborting a command on the command ring, xHC will generate a command completion event with its completion code set to Command Ring Stopped at least. If a command is currently executing at the time of aborting a command, xHC also generate a command completion event with its completion code set to Command Abort. When the command ring is stopped, software may remove, add, or rearrage Command Descriptors. To cancel a command, software will initialize a command descriptor for the cancel command, and add it into a cancel_cmd_list of xhci. When the command ring is stopped, software will find the command trbs described by command descriptors in cancel_cmd_list and modify it to No Op command. If software can't find the matched trbs, we can think it had been finished. This patch should be backported to kernels as old as 3.0, that contain the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to check for virt_dev=0 bug." That commit papers over a NULL pointer dereference, and this patch fixes the underlying issue that caused the NULL pointer dereference. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com> [bwh: Backported to 3.2: inc_deq() needs an additional 'consumer' argument; Jonathan Nieder worked out that this should be false] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Intel Panther Point BEI quirk.Sarah Sharp2012-10-173-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 80fab3b244a22e0ca539d2439bdda50e81e5666f upstream. When a device with an isochronous endpoint is behind a hub plugged into the Intel Panther Point xHCI host controller, and the driver submits multiple frames per URB, the xHCI driver will set the Block Event Interrupt (BEI) flag on all but the last TD for the URB. This causes the host controller to place an event on the event ring, but not send an interrupt. When the last TD for the URB completes, BEI is cleared, and we get an interrupt for the whole URB. However, under a Panther Point xHCI host controller, if the parent hub is unplugged when one or more events from transfers with BEI set are on the event ring, a port status change event is placed on the event ring, but no interrupt is generated. This means URBs stop completing, and the USB device disconnect is not noticed. Something like a USB headset will cause mplayer to hang when the device is disconnected. If another transfer is sent (such as running `sudo lsusb -v`), the next transfer event seems to "unstick" the event ring, the xHCI driver gets an interrupt, and the disconnect is reported to the USB core. The fix is not to use the BEI flag under the Panther Point xHCI host. This will impact power consumption and system responsiveness, because the xHCI driver will receive an interrupt for every frame in all isochronous URBs instead of once per URB. Intel chipset developers confirm that this bug will be hit if the BEI flag is used on any endpoint, not just ones that are behind a hub. This patch should be backported to kernels as old as 3.0, that contain the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support EHCI/xHCI port switching." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systemsVivek Gautam2012-10-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | commit 457a73d346187c2cc5d599072f38676f18f130e0 upstream. In 71c731a: usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware when extracting DMI strings (vendor or product_name) to mark them as quirk we may get NULL pointer in case of non-x86 systems which won't define CONFIG_DMI. Hence susbsequent strstr() calls crash while driver probing. So, returning 'false' here in case we get a NULL vendor or product_name. This is tested with ARM (exynos) system. This patch should be backported to stable kernels as old as 3.6, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Sebastian Gottschall (DD-WRT) <s.gottschall@dd-wrt.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* Increase XHCI suspend timeout to 16msMichael Spang2012-10-171-1/+1
| | | | | | | | | | | | | | | | | | commit a6e097dfdfd189b6929af6efa1d289af61858386 upstream. The Intel XHCI specification says that after clearing the run/stop bit the controller may take up to 16ms to halt. We've seen a device take 14ms, which with the current timeout of 10ms causes the kernel to abort the suspend. Increasing the timeout to the recommended value fixes the problem. This patch should be backported to kernels as old as 2.6.37, that contain the commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI: PCI power management implementation". Signed-off-by: Michael Spang <spang@chromium.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xHCI: cancel command after command timeoutElric Fu2012-10-172-7/+22
| | | | | | | | | | | | | | | | | | commit 6e4468b9a0793dfb53eb80d9fe52c739b13b27fd upstream. The patch is used to cancel command when the command isn't acknowledged and a timeout occurs. This patch should be backported to kernels as old as 3.0, that contain the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to check for virt_dev=0 bug." That commit papers over a NULL pointer dereference, and this patch fixes the underlying issue that caused the NULL pointer dereference. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xHCI: add aborting command ring functionElric Fu2012-10-174-1/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit b92cc66c047ff7cf587b318fe377061a353c120f upstream. Software have to abort command ring and cancel command when a command is failed or hang. Otherwise, the command ring will hang up and can't handle the others. An example of a command that may hang is the Address Device Command, because waiting for a SET_ADDRESS request to be acknowledged by a USB device is outside of the xHC's ability to control. To cancel a command, software will initialize a command descriptor for the cancel command, and add it into a cancel_cmd_list of xhci. Sarah: Fixed missing newline on "Have the command ring been stopped?" debugging statement. This patch should be backported to kernels as old as 3.0, that contain the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to check for virt_dev=0 bug." That commit papers over a NULL pointer dereference, and this patch fixes the underlying issue that caused the NULL pointer dereference. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xHCI: add cmd_ring_stateElric Fu2012-10-173-2/+11
| | | | | | | | | | | | | | | | | | | | | commit c181bc5b5d5c79b71203cd10cef97f802fb6f9c1 upstream. Adding cmd_ring_state for command ring. It helps to verify the current command ring state for controlling the command ring operations. This patch should be backported to kernels as old as 3.0. The commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to check for virt_dev=0 bug." papers over the NULL pointer dereference that I now believe is related to a timed out Set Address command. This (and the four patches that follow it) contain the real fix that also allows VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug stress tests. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* xhci: Warn when hosts don't halt.Sarah Sharp2012-10-171-0/+3
| | | | | | | | | | | | | | | | | commit 5af98bb06dee79d28c805f9fd0805ce791121784 upstream. Eric Fu reports a problem with his VIA host controller fetching a zeroed event ring pointer on resume from suspend. The host should have been halted, but we can't be sure because that code ignores the return value from xhci_halt(). Print a warning when the host controller refuses to halt within XHCI_MAX_HALT_USEC (currently 16 seconds). (Update: it turns out that the VIA host controller is reporting a halted state when it fetches the zeroed event ring pointer. However, we still need this warning for other host controllers.) Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* EHCI: Update qTD next pointer in QH overlay region during unlinkPavankumar Kondeti2012-09-191-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream. There is a possibility of QH overlay region having reference to a stale qTD pointer during unlink. Consider an endpoint having two pending qTD before unlink process begins. The endpoint's QH queue looks like this. qTD1 --> qTD2 --> Dummy To unlink qTD2, QH is removed from asynchronous list and Asynchronous Advance Doorbell is programmed. The qTD1's next qTD pointer is set to qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell interrupt. If QH's current qTD pointer points to qTD1, transfer overlay region still have reference to qTD2. But qtD2 is just unlinked and freed. This may cause EHCI system error. Fix this by updating qTD next pointer in QH overlay region with the qTD next pointer of the current qTD. Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: host: xhci: fix compilation error for non-PCI based stacksMoiz Sonasath2012-09-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | commit 296365781903226a3fb8758901eaeec09d2798e4 upstream. For non PCI-based stacks, this function call usb_disable_xhci_ports(to_pci_dev(hcd->self.controller)); made from xhci_shutdown is not applicable. Ideally, we wouldn't have any PCI-specific code on a generic driver such as the xHCI stack, but it looks like we should just stub usb_disable_xhci_ports() out for non-PCI devices. [ balbi@ti.com: slight improvement to commit log ] This patch should be backported to kernels as old as 3.0, since the commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch PPT ports to EHCI on shutdown.") was marked for stable. Signed-off-by: Moiz Sonasath<m-sonasath@ti.com> Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
* usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP HardwareAlexis R. Cortes2012-09-193-0/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 upstream. This patch is intended to work around a known issue on the SN65LVPE502CP USB3.0 re-driver that can delay the negotiation between a device and the host past the usual handshake timeout. If that happens on the first insertion, the host controller port will enter in Compliance Mode and NO port status event will be generated (as per xHCI Spec) making impossible to detect this event by software. The port will remain in compliance mode until a warm reset is applied to it. As a result of this, the port will seem "dead" to the user and no device connections or disconnections will be detected. For solving this, the patch creates a timer which polls every 2 seconds the link state of each host controller's port (this by reading the PORTSC register) and recovers the port by issuing a Warm reset every time Compliance mode is detected. If a xHC USB3.0 port has previously entered to U0, the compliance mode issue will NOT occur only until system resumes from sleep/hibernate, therefore, the compliance mode timer is stopped when all xHC USB 3.0 ports have entered U0. The timer is initialized again after each system resume. Since the issue is being caused by a piece of hardware, the timer will be enabled ONLY on those systems that have the SN65LVPE502CP installed (this patch uses DMI strings for detecting those systems) therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK has been added to the xhci stack). This patch applies for these systems: Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820. This patch should be backported to kernels as old as 3.2, as that was the first kernel to support warm reset. The kernels will need to contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When hot reset for USB3 fails, try warm reset" and commit 8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub port status CAS". The first patch add warm reset support, and the second patch modifies the USB core to issue a warm reset when the port is in compliance mode. Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
generated by cgit v1.1 at 2024-05-24 05:47:02 +0000