summaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/xhci.h
Commit message (Collapse)AuthorAgeFilesLines
* xhci: mediatek: support MTK xHCI host controllerChunfeng Yun2015-12-011-0/+1
| | | | | | | | | | | | | | | | | | | There some vendor quirks for MTK xhci host controller: 1. It defines some extra SW scheduling parameters for HW to minimize the scheduling effort for synchronous and interrupt endpoints. The parameters are put into reseved DWs of slot context and endpoint context. 2. Its IMODI unit for Interrupter Moderation register is 8 times as much as that defined in xHCI spec. 3. Its TDS in Normal TRB defines a number of packets that remains to be transferred for a TD after processing all Max packets in all previous TRBs. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Tested-by: Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: host: xhci: add a platform-private fieldYoshihiro Shimoda2015-12-011-0/+3
| | | | | | | | | | This patch adds an xhci->priv field for private use by XHCI platform drivers. Until now none of the platform drivers has used this private space. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'asm-generic-for-linus' of ↵Linus Torvalds2015-11-061-2/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull asm-generic cleanups from Arnd Bergmann: "The asm-generic changes for 4.4 are mostly a series from Christoph Hellwig to clean up various abuses of headers in there. The patch to rename the io-64-nonatomic-*.h headers caused some conflicts with new users, so I added a workaround that we can remove in the next merge window. The only other patch is a warning fix from Marek Vasut" * tag 'asm-generic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: asm-generic: temporarily add back asm-generic/io-64-nonatomic*.h asm-generic: cmpxchg: avoid warnings from macro-ized cmpxchg() implementations gpio-mxc: stop including <asm-generic/bug> n_tracesink: stop including <asm-generic/bug> n_tracerouter: stop including <asm-generic/bug> mlx5: stop including <asm-generic/kmap_types.h> hifn_795x: stop including <asm-generic/kmap_types.h> drbd: stop including <asm-generic/kmap_types.h> move count_zeroes.h out of asm-generic move io-64-nonatomic*.h out of asm-generic
* | xhci: replace custom implementation of readq / writeqAndy Shevchenko2015-10-161-10/+4
| | | | | | | | | | | | | | | | | | | | The readq() and writeq() helpers are available in the asm-generic/io-64-nonatomic-hi-lo.h and asm-generic/io-64-nonatomic-lo-hi.h headers. Replace custom implementation by the generic helpers. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | xhci: create one unified function to calculate TRB TD remainder.Mathias Nyman2015-10-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | xhci versions 1.0 and later report the untransferred data remaining in a TD a bit differently than older hosts. We used to have separate functions for these, and needed to check host version before calling the right function. Now Mediatek host has an additional quirk on how it uses the TD Size field for remaining data. To prevent yet another function for calculating remainder we instead want to make one quirk friendly unified function. Tested-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | xhci: support new USB 3.1 hub request to get extended port statusMathias Nyman2015-10-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | USB 3.1 adds different types of Get Port Status request. The Get Extended Port Status request returns 4 additional bytes after the normal portstatus and portchange words containing link speed and lane information about a connected enhanced super speed device Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | xhci: define the new default speed ID for SuperSpeedPlus used by xhci hwMathias Nyman2015-10-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | USB 3.1 capable xhci controllers use a new default speed ID "5" in the PORTSC register to represent a 10Gbps connection speed of a SuperSpeedPlus device Make sure the xhci driver can handle the returned SuperSpeedPlus speed ID properly Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | xhci: parse xhci protocol speed ID list for usb 3.1 usageMathias Nyman2015-10-041-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | xhci 1.1 controllers that support USB 3.1 must provide a protocol speed ID (PSI) list to inform the driver of the supported speeds. The PSI list can be read from the xhci supported protocol extended capabilities. The PSI values will be used to create a USB 3.1 SuperSpeedPlus capability descriptor for the xhci USB 3.1 roothub. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | xhci: Read and parse new xhci 1.1 capability registerLu Baolu2015-10-041-1/+23
|/ | | | | | | | | | | | | xhci 1.1 capable controllers have a new HCCPARAMS2 registers with bits indicating support for new xhci 1.1 capabilities. Also add support for the new xhci 1.1 bits in the config operational opertational register that used to be reserved Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> [modified and left out parts not related to HCCPARAMS2 -Mathias] Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: xHCI 1.1: Stopped - Short Packet Capability (SPC)Lu Baolu2015-08-081-2/+4
| | | | | | | | | | | | | | | | | | This patch enables xhci driver to support SPC by handling Stopped - Short Packet event in transfer event path. If SPC = '1' and the stop endpoint command is executed, after a Short Packet condition has been detected, but before the end of the TD has been reached, (i.e. the TD is in progress for pipe), then a Transfer Event TRB with its Completion Code set to Stopped - Short Packet and its TRB Transfer Length set to value of the EDTLA shall be forced for the interrupted TRB, irrespective of whether its IOC or ISP flags are set. This Transfer Event TRB will precede the Command Completion Event TRB for the command, and is referred to as a Stopped Transfer Event. Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: xHCI 1.1: Contiguous Frame ID Capability (CFC)Lu Baolu2015-08-081-0/+7
| | | | | | | | | | | | | | | | If the Contiguous Frame ID Capability is supported (CFC = 1), then the xHC shall match the Frame ID in every Isoch TD with SIA = 0 against the Frame Index of the MFINDEX register. This rule ensures resynchronization of Isoch TDs even if some are dropped due to Missed Service Errors or Stopping the endpoint. This patch enables xHCI driver to support CFC by calculating and setting the Frame ID field of an Isoch TRB. [made some dbg messages checkpatch friendly -Mathias] Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: prevent bus_suspend if SS port resuming in phase 1Zhuang Jin Can2015-07-221-0/+1
| | | | | | | | | | | | | | | | | | | When the link is just waken, it's in Resume state, and driver sets PLS to U0. This refers to Phase 1. Phase 2 refers to when the link has completed the transition from Resume state to U0. With the fix of xhci: report U3 when link is in resume state, it also exposes an issue that usb3 roothub and controller can suspend right after phase 1, and this causes a hard hang in controller. To fix the issue, we need to prevent usb3 bus suspend if any port is resuming in phase 1. [merge separate USB2 and USB3 port resume checking to one -Mathias] Cc: <stable@vger.kernel.org> Signed-off-by: Zhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge 4.1-rc7 into usb-nextGreg Kroah-Hartman2015-06-081-0/+2
|\ | | | | | | | | | | | | This resolves a merge issue in musb_core.c and we want the fixes that were in Linus's tree in this branch as well for testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: host: xhci: add mutex for non-thread-safe dataChris Bainbridge2015-05-241-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regression in commit 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") The regression resulted in intermittent failure to initialise a 10-port hub (with three internal VL812 4-port hub controllers) on boot, with a failure rate of around 8%, due to multiple race conditions when accessing addr_dev and slot_id in struct xhci_hcd. This regression also exposed a problem with xhci_setup_device, which "should be protected by the usb_address0_mutex" but no longer is due to commit 6fecd4f2a58c ("USB: separate usb_address0 mutexes for each bus") With separate buses (and locks) it is no longer the case that a single lock will protect xhci_setup_device from accesses by two parallel threads processing events on the two buses. Fix this by adding a mutex to protect addr_dev and slot_id in struct xhci_hcd, and by making the assignment of slot_id atomic. Fixes multiple boot errors: [ 0.583008] xhci_hcd 0000:00:14.0: Bad Slot ID 2 [ 0.583009] xhci_hcd 0000:00:14.0: Could not allocate xHCI USB device data structures [ 0.583012] usb usb1-port3: couldn't allocate usb_device And: [ 0.637409] xhci_hcd 0000:00:14.0: Error while assigning device slot ID [ 0.637417] xhci_hcd 0000:00:14.0: Max number of devices this xHCI host supports is 32. [ 0.637421] usb usb1-port1: couldn't allocate usb_device And: [ 0.753372] xhci_hcd 0000:00:14.0: ERROR: unexpected setup context command completion code 0x0. [ 0.753373] usb 1-3: hub failed to enable device, error -22 [ 0.753400] xhci_hcd 0000:00:14.0: Error while assigning device slot ID [ 0.753402] xhci_hcd 0000:00:14.0: Max number of devices this xHCI host supports is 32. [ 0.753403] usb usb1-port3: couldn't allocate usb_device And: [ 11.018386] usb 1-3: device descriptor read/all, error -110 And: [ 5.753838] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command Tested with 200 reboots, resulting in no USB hub init related errors. Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Link: https://lkml.kernel.org/g/CAP-bSRb=A0iEYobdGCLpwynS7pkxpt_9ZnwyZTPVAoy0Y=Zo3Q@mail.gmail.com Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com> Cc: <stable@vger.kernel.org> # 3.18+ [changed git commit description style for checkpatch -Mathias] Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | usb: xhci: cleanup xhci_hcd allocationRoger Quadros2015-05-311-2/+17
|/ | | | | | | | | | | | | | | HCD core allocates memory for HCD private data in usb_create_[shared_]hcd() so make use of that mechanism to allocate the struct xhci_hcd. Introduce struct xhci_driver_overrides to provide the size of HCD private data and hc_driver operation overrides. As of now we only need to override the reset and start methods. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Solve full event ring by increasing TRBS_PER_SEGMENT to 256Mathias Nyman2015-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our event ring consists of only one segment, and we risk filling the event ring in case we get isoc transfers with short intervals such as webcams that fill a TD every microframe (125us) With 64 TRB segment size one usb camera could fill the event ring in 8ms. A setup with several cameras and other devices can fill up the event ring as it is shared between all devices. This has occurred when uvcvideo queues 5 * 32TD URBs which then get cancelled when the video mode changes. The cancelled URBs are returned in the xhci interrupt context and blocks the interrupt handler from handling the new events. A full event ring will block xhci from scheduling traffic and affect all devices conneted to the xhci, will see errors such as Missed Service Intervals for isoc devices, and and Split transaction errors for LS/FS interrupt devices. Increasing the TRB_PER_SEGMENT will also increase the default endpoint ring size, which is welcome as for most isoc transfer we had to dynamically expand the endpoint ring anyway to be able to queue the 5 * 32TDs uvcvideo queues. The default size used to be 64 TRBs per segment Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Revert "xhci: Clear the host side toggle manually when endpoint is 'soft reset'"Mathias Nyman2015-03-111-2/+0
| | | | | | | | | | | | | | | This reverts commit 27082e2654dc ("xhci: Clear the host side toggle manually") Turns out this fix to enable soft resetting endpoints wasn't mature enough. It caused regression with some usb DVB-T devices and needs some more tuning to get the endpiont ring pointers set correctly. The original commit was tagged for stable 3.18, and should be reverted from there as well. Cc: stable <stable@vger.kernel.org> # v3.18 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Workaround for PME stuck issues in Intel xhciMathias Nyman2015-03-061-0/+1
| | | | | | | | | | | | | | | | The xhci in Intel Sunrisepoint and Cherryview platforms need a driver workaround for a Stuck PME that might either block PME events in suspend, or create spurious PME events preventing runtime suspend. Workaround is to clear a internal PME flag, BIT(28) in a vendor specific PMCTRL register at offset 0x80a4, in both suspend resume callbacks Without this, xhci connected usb devices might never be able to wake up the system from suspend, or prevent device from going to suspend (xhci d3) Cc: <stable@vger.kernel.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: fix reporting of 0-sized URBs in control endpointAleksander Morgado2015-03-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | When a control transfer has a short data stage, the xHCI controller generates two transfer events: a COMP_SHORT_TX event that specifies the untransferred amount, and a COMP_SUCCESS event. But when the data stage is not short, only the COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless urb->actual_length was set already by a previous COMP_SHORT_TX event. The driver checks this by seeing whether urb->actual_length == 0, but this alone is the wrong test, as it is entirely possible for a short transfer to have an urb->actual_length = 0. This patch changes the xhci driver to rely on a new td->urb_length_set flag, which is set to true when a COMP_SHORT_TX event is received and the URB length updated at that stage. This fixes a bug which affected the HSO plugin, which relies on URBs with urb->actual_length == 0 to halt re-submitting the RX URB in the control endpoint. Cc: <stable@vger.kernel.org> Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Clear the host side toggle manually when endpoint is 'soft reset'Mathias Nyman2015-02-241-0/+2
| | | | | | | | | | | | | | | Main benefit of this is to get xhci connected USB scanners to work. Some devices use a clear endpoint halt request as a 'soft reset' even if the endpoint is not halted. This will clear the toggle and sequence on the device side. xHCI however refuses to reset a non-halted endpoint, so instead we need to issue a configure endpoint command on xHCI to clear its host side toggle and sequence, and get it in sync with the device side. Tested-by: Mike Mammarella <mikem@crystalorb.net> Cc: <stable@vger.kernel.org> # v3.18 Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Allocate correct amount of scratchpad buffersMathias Nyman2015-02-241-2/+3
| | | | | | | | | | | | | | | | | Include the high order bit fields for Max scratchpad buffers when calculating how many scratchpad buffers are needed. I'm suprised this hasn't caused more issues, we never allocated more than 32 buffers even if xhci needed more. Either we got lucky and xhci never really used past that area, or then we got enough zeroed dma memory anyway. Should be backported as far back as possible Reported-by: Tim Chen <tim.c.chen@linux.intel.com> Tested-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Print hcc params, version and quirks on initHans de Goede2015-01-251-0/+2
| | | | | | | | To help debugging xhci problems. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: clean up work to remove unused parameters for functions in xhci-mem.cLin Wang2015-01-091-4/+3
| | | | | | | | | | | | Some parameters are not used by functions in xhci-mem.c, just remove it. Changes compared to v1: - Rebase to the latest usb-next branch Signed-off-by: Lin Wang <lin.x.wang@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: remove unused parameter 'xhci' in function xhci_handshake().Lin Wang2015-01-091-2/+1
| | | | | | | | | Parameter 'xhci' is no longer be used in function xhci_handshake(), just remove it. Signed-off-by: Lin Wang <lin.x.wang@intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: fix comment for PORT_DEV_REMOVELu Baolu2014-12-021-1/+1
| | | | | | | | | | According to xHCI specification, PORT_DEV_REMOVE(bit 30) in PORTSC true means "Device is non-removable". Reported-by: Juro Bystricky <jurobystricky@hotmail.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: don't use the same variable for stopped and halted rings current TDMathias Nyman2014-12-021-1/+1
| | | | | | | | | | | | | Endpoints halted on errors, and endpoints stopped manually both used the same ep->stopped_td to store the halted or stopped td. this causes confusion and possible races. There is no longer a need to use the ep->stopped_td variable to store the halted TD. A halted endpoint is handled immediately and we can pass it to the handling function directly. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: rework root port wake bits if controller isn't allowed to wakeupLu Baolu2014-11-221-1/+1
| | | | | | | | | | | | | | | | | | When system is being suspended, if host device is not allowed to do wakeup, xhci_suspend() needs to clear all root port wake on bits. Otherwise, some platforms may generate spurious wakeup, even if PCI PME# is disabled. The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"), which also got into stable, turned out to not work correctly and had to be reverted, and is now rewritten. Cc: stable <stable@vger.kernel.org> # v3.2+ Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Alan Stern <stern@rowland.harvard.edu> [Mathias Nyman: reword commit message] Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Allow xHCI drivers to be built as separate modulesAndrew Bresticker2014-10-031-19/+0
| | | | | | | | | | | | Instead of building all of the xHCI code into a single module, separate it out into the core (xhci-hcd), PCI (xhci-pci, now selected by the new config option CONFIG_USB_XHCI_PCI), and platform (xhci-plat) drivers. Also update the PCI/platform drivers with module descriptions/licenses and have them register their respective drivers in their initcalls. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3coldAndrew Bresticker2014-10-031-3/+0
| | | | | | | | | | | Instead of calling xhci_compliance_mode_recovery_timer_quirk_check() again in the PCI suspend path, just check for XHCI_COMP_MODE_QUIRK which will have been set based on xhci_compliance_mode_recovery_timer_quirk_check() in xhci_init(). Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Introduce xhci_init_driver()Andrew Bresticker2014-10-031-0/+1
| | | | | | | | | | | | | | | Since the struct hc_driver is mostly the same across the xhci-pci, xhci-plat, and the upcoming xhci-tegra driver, introduce the function xhci_init_driver() which will populate the hc_driver with the default xHCI operations. The caller must supply a setup function which will be used as the hc_driver's reset callback. Note that xhci-plat also overrides the default ->start() callback so that it can do rcar-specific initialization. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Log extra info on "ERROR Transfer event TRB DMA ptr not part of ↵Hans de Goede2014-09-231-3/+3
| | | | | | | | | | | | | current TD" Lately (with the use of uas / bulk-streams) we have been seeing several cases where this error triggers (which should never happen). Add some extra logging to make debugging these errors easier. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Move allocating of command for new_dequeue_state to queue_set_tr_deq()Hans de Goede2014-09-231-1/+0
| | | | | | | | | | | | | | | | | | There are multiple reasons for this: 1) This fixes a missing check for xhci_alloc_command failing in xhci_handle_cmd_stop_ep() 2) This adds a warning when we cannot set the new dequeue state because of xhci_alloc_command failing 3) It puts the allocation of the command after the sanity checks in queue_set_tr_deq(), avoiding leaking the command if those fail 4) Since queue_set_tr_deq now owns the command it can free it if queue_command fails 5) It reduces code duplication Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Blacklist using streams on the Etron EJ168 controllerHans de Goede2014-08-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Streams on the EJ168 do not work as they should. I've spend 2 days trying to get them to work, but without success. The first problem is that when ever you ring the stream-ring doorbell, the controller starts executing trbs at the beginning of the first ring segment, event if it ended somewhere else previously. This can be worked around by allowing enqueing only one td (not a problem with how streams are typically used) and then resetting our copies of the enqueueing en dequeueing pointers on a td completion to match what the controller seems to be doing. This way things seem to start working with uas and instead of being able to complete only the very first scsi command, the scsi core can probe the disk. But then things break later on when td-s get enqueued with more then one trb. The controller does seem to increase its dequeue pointer while executing a stream-ring (data transfer events I inserted for debugging do trigger). However execution seems to stop at the final normal trb of a multi trb td, even if there is a data transfer event inserted after the final trb. The first problem alone is a serious deviation from the spec, and esp. dealing with cancellation would have been very tricky if not outright impossible, but the second problem simply is a deal breaker altogether, so this patch simply disables streams. Note this will cause the usb-storage + uas driver pair to automatically switch to using usb-storage instead of uas on these devices, essentially reverting to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN. https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=80101 Cc: stable@vger.kernel.org # 3.15 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: host: xhci-plat: add clock supportGregory CLEMENT2014-05-271-0/+2
| | | | | | | | | | | | | | | | | | Some platforms (such as the Armada 38x ones) can gate the clock of their USB controller. This patch adds the support for one clock in xhci-plat, by enabling it during probe and disabling it on remove. To achieve this, it adds a 'struct clk *' member in xhci_hcd. While only used for now in xhci-plat, it might be used by other drivers in the future. Moreover, the xhci_hcd structure already holds other members such as msix_count and msix_entries, which are MSI-X specific, and therefore only used by xhci-pci. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Felipe Balbi <balbi@ti.com> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: rework command timeout and cancellation,Mathias Nyman2014-05-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use one timer to control command timeout. start/kick the timer every time a command is completed and a new command is waiting, or a new command is added to a empty list. If the timer runs out, then tag the current command as "aborted", and start the xhci command abortion process. Previously each function that submitted a command had its own timer. If that command timed out, a new command structure for the command was created and it was put on a cancel_cmd_list list, then a pci write to abort the command ring was issued. when the ring was aborted, it checked if the current command was the one to be canceled, later when the ring was stopped the driver got ownership of the TRBs in the command ring, compared then to the TRBs in the cancel_cmd_list, and turned them into No-ops. Now, instead, at timeout we tag the status of the command in the command queue to be aborted, and start the ring abortion. Ring abortion stops the command ring and gives control of the commands to us. All the aborted commands are now turned into No-ops. If the ring is already stopped when the command times outs its not possible to start the ring abortion, in this case the command is turnd to No-op right away. All these changes allows us to remove the entire cancel_cmd_list code. The functions waiting for a command to finish no longer have their own timeouts. They will wait either until the command completes normally, or until the whole command abortion is done. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Use completion and status in global command queueMathias Nyman2014-05-201-3/+0
| | | | | | | | | Remove the per-device command list and handle_cmd_in_cmd_wait_list() and use the completion and status variables found in the command structure in the global command list. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Add a global command queueMathias Nyman2014-05-201-0/+2
| | | | | | | | | | | | | | Create a list to store command structures, add a structure to it every time a command is submitted, and remove it from the list once we get a command completion event matching the command. Callers that wait for completion will free their command structures themselves. The other command structures are freed in the command completion event handler. Also add a check that prevents queuing commands if host is dying Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Use command structures when queuing commands on the command ringMathias Nyman2014-05-201-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To create a global command queue we require that each command put on the command ring is submitted with a command structure. Functions that queue commands and wait for completion need to allocate a command before submitting it, and free it once completed. The following command queuing functions need to be modified. xhci_configure_endpoint() xhci_address_device() xhci_queue_slot_control() xhci_queue_stop_endpoint() xhci_queue_new_dequeue_state() xhci_queue_reset_ep() xhci_configure_endpoint() xhci_configure_endpoint() could already be called with a command structure, and only xhci_check_maxpacket and xhci_check_bandwidth did not do so. These are changed and a command structure is now required. This change also simplifies the configure endpoint command completion handling and the "goto bandwidth_change" handling code can be removed. In some cases the command queuing function is called in interrupt context. These commands needs to be allocated atomically, and they can't wait for completion. These commands will in this patch be freed directly after queuing, but freeing will be moved to the command completion event handler in a later patch once we get the global command queue up.(Just so that we won't leak memory in the middle of the patch set) Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: Use IS_ENABLED() macroFabio Estevam2014-05-201-2/+1
| | | | | | | | Using the IS_ENABLED() macro can make the code shorter and easier to read. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: xhci: Prefer endpoint context dequeue pointer over stopped_trbJulius Werner2014-04-251-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have observed a rare cycle state desync bug after Set TR Dequeue Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that doesn't fetch new TRBs and thus an unresponsive USB device). It always triggers when a previous Set TR Dequeue Pointer command has set the pointer to the final Link TRB of a segment, and then another URB gets enqueued and cancelled again before it can be completed. Further investigation showed that the xHC had returned the Link TRB in the TRB Pointer field of the Transfer Event (CC == Stopped -- Length Invalid), but when xhci_find_new_dequeue_state() later accesses the Endpoint Context's TR Dequeue Pointer field it is set to the first TRB of the next segment. The driver expects those two values to be the same in this situation, and uses the cycle state of the latter together with the address of the former. This should be fine according to the XHCI specification, since the endpoint ring should be stopped when returning the Transfer Event and thus should not advance over the Link TRB before it gets restarted. However, real-world XHCI implementations apparently don't really care that much about these details, so the driver should follow a more defensive approach to try to work around HC spec violations. This patch removes the stopped_trb variable that had been used to store the TRB Pointer from the last Transfer Event of a stopped TRB. Instead, xhci_find_new_dequeue_state() now relies only on the Endpoint Context, requiring a small amount of additional processing to find the virtual address corresponding to the TR Dequeue Pointer. Some other parts of the function were slightly rearranged to better fit into this model. This patch should be backported to kernels as old as 2.6.31 that contain the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB cancellation support." Signed-off-by: Julius Werner <jwerner@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: For streams the dequeue ptr must be read from the stream ctxHans de Goede2014-03-041-0/+1
| | | | | | | | | | | | | | This fixes TR dequeue validation failing on Intel XHCI controllers with the following warning: Mismatch between completed Set TR Deq Ptr command & xHCI internal state. Interestingly enough reading the deq ptr from the ep ctx after a TR Deq Ptr command does work on a Nec XHCI controller, it seems the Nec writes the ptr to both the ep and stream contexts when streams are used. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Set SCT field for Set TR dequeue on streamsHans de Goede2014-03-041-1/+2
| | | | | | | | | | | | | Nec XHCI controllers don't seem to care, but without this Intel XHCI controllers reject Set TR dequeue commands with a COMP_TRB_ERR, leading to the following warning: WARN Set TR Deq Ptr cmd invalid because of stream ID configuration And very shortly after this the system completely freezes. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: fix usb3 streamsGerd Hoffmann2014-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | xhci maintains a radix tree for each stream endpoint because it must be able to map a trb address to the stream ring. Each ring segment must be added to the ring for this to work. Currently xhci sticks only the first segment of each stream ring into the radix tree. Result is that things work initially, but as soon as the first segment is full xhci can't map the trb address from the completion event to the stream ring any more -> BOOM. You'll find this message in the logs: ERROR Transfer event for disabled endpoint or incorrect stream ring This patch adds a helper function to update the radix tree, and a function to remove ring segments from the tree. Both functions loop over the segment list and handles all segments instead of just the first. [Note: Sarah changed this patch to add radix_tree_maybe_preload() and radix_tree_preload_end() calls around the radix tree insert, since we can now insert entries in interrupt context. There are now two helper functions to make the code cleaner, and those functions are moved to make them static.] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Revert "xhci: Set scatter-gather limit to avoid failed block writes."Sarah Sharp2014-02-071-1/+1
| | | | | | | | | | | | | This reverts commit f2d9b991c549f159dc9ae81f77d8206c790cbfee. We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB must not occur within a USB payload burst" because it's a hack that caused regressions in the usb-storage and userspace USB drivers that use usbfs and libusb. This commit attempted to fix the issues with that patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org #3.12
* Revert "xhci: replace xhci_read_64() with readq()"Sarah Sharp2014-01-301-2/+8
| | | | | | | | | This reverts commit e8b373326d8efcaf9ec1da8b618556c89bd5ffc4. Many xHCI host controllers can only handle 32-bit addresses, and writing 64-bits at a time causes them to fail. Reading 64-bits at a time may also cause them to return 0xffffffff, so revert this commit as well. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Revert "xhci: replace xhci_write_64() with writeq()"Sarah Sharp2014-01-291-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 7dd09a1af2c7150269350aaa567a11b06e831003. Many xHCI host controllers can only handle 32-bit addresses, and writing 64-bits at a time causes them to fail. Rafał reports that USB devices simply do not enumerate, and reverting this patch helps. Branimir reports that his host controller doesn't respond to an Enable Slot command and dies: [ 75.576160] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 88.991634] xhci_hcd 0000:03:00.0: Stopped the command ring failed, maybe the host is dead [ 88.991748] xhci_hcd 0000:03:00.0: Abort command ring failed [ 88.991845] xhci_hcd 0000:03:00.0: HC died; cleaning up [ 93.985489] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 93.985494] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead. [ 98.982586] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 98.982591] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead. [ 103.979696] xhci_hcd 0000:03:00.0: Timeout while waiting for a slot [ 103.979702] xhci_hcd 0000:03:00.0: Abort the command ring, but the xHCI is dead Signed-off-by: Sarah Sharp <sarah.a.sharp@intel.com> Reported-by: Rafał Miłecki <zajec5@gmail.com> Reported-by: Branimir Maksimovic <branimir.maksimovic@gmail.com> Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
* xhci: Set scatter-gather limit to avoid failed block writes.Sarah Sharp2014-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB must not occur within a USB payload burst" attempted to fix an issue found with USB ethernet adapters, and inadvertently broke USB storage devices. The patch attempts to ensure that transfers never span a segment, and rejects transfers that have more than 63 entries (or possibly less, if some entries cross 64KB boundaries). usb-storage limits the maximum transfer size to 120K, and we had assumed the block layer would pass a scatter-gather list of 4K entries, resulting in no more than 31 sglist entries: http://marc.info/?l=linux-usb&m=138498190419312&w=2 That assumption was wrong, since we've seen the driver reject a write that was 218 sectors long (of probably 512 bytes each): Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63 ... Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00 Limit the number of scatter-gather entries to half a ring segment. That should be margin enough in case some entries cross 64KB boundaries. Increase the number of TRBs per segment from 64 to 256, which should result in ring segments fitting on a 4K page. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: jidanni@jidanni.org References: http://bugs.debian.org/733907 Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload burst') Cc: stable <stable@vger.kernel.org> # 3.12
* usb: xhci: change enumeration scheme to 'new scheme' by defaultDan Williams2013-12-101-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: David Moore <david.moore@gmail.com> Suggested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: replace xhci_write_64() with writeq()Xenia Ragiadakou2013-12-021-20/+9
| | | | | | | | | | | | | | | | | Function xhci_write_64() is used to write 64bit xHC registers residing in MMIO. On 32bit systems, xHC registers need to be written with 32bit accesses by writing first the lower 32bits and then the higher 32bits. The header file asm-generic/io-64-nonatomic-lo-hi.h ensures that on 32bit systems writeq() will will write 64bit registers in 32bit chunks with low-high order. Replace all calls to xhci_write_64() with calls to writeq(). This is done to reduce code duplication since 64bit low-high write logic is already implemented and to take advantage of inherent "atomic" 64bit write operations on 64bit systems. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: replace xhci_read_64() with readq()Xenia Ragiadakou2013-12-021-8/+2
| | | | | | | | | | | | | | | | | Function xhci_read_64() is used to read 64bit xHC registers residing in MMIO. On 32bit systems, xHC registers need to be read with 32bit accesses by reading first the lower 32bits and then the higher 32bits. Replace all calls to xhci_read_64() with calls to readq() and include asm-generic/io-64-nonatomic-lo-hi.h header file, so that if the system is not 64bit, readq() will read registers in 32bit chunks with low-high order. This is done to reduce code duplication since 64bit low-high read logic is already implemented and to take advantage of inherent "atomic" 64bit read operations on 64bit systems. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
OpenPOWER on IntegriCloud