summaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/xhci-hub.c
Commit message (Collapse)AuthorAgeFilesLines
* xhci: add trace for debug messages related to quirksXenia Ragiadakou2013-08-131-2/+5
| | | | | | | | | This patch defines a new trace event, which is called xhci_dbg_quirks and belongs in the event class xhci_log_msg, and adds tracepoints that trace the debug messages associated with xHCs' quirks. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Report USB 2.1 link status for L1Sarah Sharp2013-07-231-3/+12
| | | | | | | | | | | | | | | | | | | USB 2.1 devices can go into a lower power link state, L1. When they are active, they are in the L0 state. The L1 transition can be purely driven by software, or some USB host controllers (including some xHCI 1.0 hosts) allow the host hardware to track idleness and automatically place a port into L1. The USB 2.1 Link Power Management ECN gives a way for USB 2.1 hubs that support LPM to report that a port is in L1. The port status bit 5 will be set when the port is in L1. The xHCI host reports the root port as being in 'U2' when the devices is in L1, and as being in 'U0' when the port is active (in L0). Translate the xHCI USB 2.1 link status into the format external hubs use, and pass the L1 status up to the USB core and tools like lsusb. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Refactor port status into a new function.Sarah Sharp2013-07-231-91/+119
| | | | | | | The hub control function is *way* too long. Refactor it into a new function, and document the side effects of calling that function. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* usb: xhci: define port register names and use them instead of magic numbersMathias Nyman2013-06-051-9/+7
| | | | | Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* USB: remove CONFIG_USB_SUSPEND optionAlan Stern2013-03-281-1/+1
| | | | | | | | | | | | | | | | | This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially replacing it everywhere with CONFIG_PM_RUNTIME (except for one place in hub.c, where it is replaced with CONFIG_PM because the code needs to be used in both runtime and system PM). The net result is code shrinkage and simplification. There's very little point in keeping CONFIG_USB_SUSPEND because almost everybody enables it. The few that don't will find that the usbcore module has gotten somewhat bigger and they will have to take active measures if they want to prevent hubs from being runtime suspended. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xhci: Avoid "dead ports", add roothub port polling.Sarah Sharp2013-01-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Cc: stable@vger.kernel.org
* USB: Allow USB 3.0 ports to be disabled.Sarah Sharp2013-01-031-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Cc: stable@vger.kernel.org
* usb/xhci: Remove (__force__ __u16) before assigning DeviceRemovable and ↵Lan Tianyu2012-10-221-3/+2
| | | | | | | | | | assign directly. Struct usb_hub_descriptor.ss.DeviceRemovable has been defined as __le16 and (__force__ __u16) doesn't need. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* usb/xhci: release xhci->lock during turning on/off usb port's acpi power ↵Lan Tianyu2012-10-221-0/+4
| | | | | | | | | | | | resource and checking the existence of port's power resource When setting usb port's acpi power resource, there will be some xhci hub requests. This will cause dead lock since xhci->lock has been held before setting acpi power resource in the xhci_hub_control(). The usb_acpi_power_manageable() function might fall into sleep so release xhci->lock before invoking it. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Merge 3.6-rc6 into usb-nextGreg Kroah-Hartman2012-09-161-0/+42
|\ | | | | | | | | | | | | | | | | This resolves the merge problems with: drivers/usb/dwc3/gadget.c drivers/usb/musb/tusb6010.c that had been seen in linux-next. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP HardwareAlexis R. Cortes2012-09-051-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> Cc: stable@vger.kernel.org
* | usb/xhci: update a comment regarding the BOS descriptor to reflect the codeSebastian Andrzej Siewior2012-09-131-1/+1
| | | | | | | | | | | | | | | | The comment is a quote of Alan Stern and reflects the data structure better than the the initial comment. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | usb: host: xhci: sparse fixesFelipe Balbi2012-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | drivers/usb/host/xhci.c:1826:14: warning: symbol 'xhci_get_block_size' was not declared. Should it be static? drivers/usb/host/xhci.c:1844:14: warning: symbol 'xhci_get_largest_overhead' was not declared. Should it be static? drivers/usb/host/xhci-ring.c:2304:36: warning: context imbalance in 'handle_tx_event' - unexpected unlock drivers/usb/host/xhci-hub.c:425:6: warning: symbol 'xhci_set_remote_wake_mask' was not declared. Should it be static? Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | usb/acpi: Use ACPI methods to power off ports.Lan Tianyu2012-09-101-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upcoming Intel systems will have an ACPI method to control whether a USB port can be completely powered off. The implication of powering off a USB port is that the device and host sees a physical disconnect, and subsequent port connections and remote wakeups will be lost. Add a new function, usb_acpi_power_manageable(), that can be used to find whether the usb port has ACPI power resources that can be used to power on and off the port on these machines. Also add a new function called usb_acpi_set_power_state() that controls the port power via these ACPI methods. When the USB core calls into the xHCI hub driver to power off a port, check whether the port can be completely powered off via this new ACPI mechanism. If so, call into these new ACPI methods. Also use the ACPI methods when the USB core asks to power on a port. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | xhci: Handle clear PORT_POWER feature.Lan Tianyu2012-09-101-0/+4
|/ | | | | | | | | This patch makes the xHCI roothub code handle the clear PORT_POWER feature request. Setting port power is already handled. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'for-usb-next-2012-07-11' of ↵Greg Kroah-Hartman2012-07-161-0/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-next USB: Link PM fixes and Latency Tolerance Messaging Hi Greg, Here's four bug fix patches for Link PM (LPM), which are marked for 3.5-stable. There's also three patches that turn on Latency Tolerance Messaging (LTM) for xHCI host controllers and USB 3.0 devices that support this low power feature. Please queue for 3.6. Sarah Sharp
| * xhci: Export Latency Tolerance Messaging capabilities.Sarah Sharp2012-07-111-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Some xHCI host controllers may have optional support for Latency Tolerance Messaging (LTM). This allows USB 3.0 devices that support LTM to pass information about how much latency they can tolerate to the xHC. A PCI xHCI host will use this information to update the PCI Latency Tolerance Request (LTR) info. The goal of this is to gather latency information for the system, to enable hardware-driven C states, and the shutting down of PLLs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | usb: Add support for root hub port status CASStanislaw Ledwon2012-07-021-6/+38
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The host controller port status register supports CAS (Cold Attach Status) bit. This bit could be set when USB3.0 device is connected when system is in Sx state. When the system wakes to S0 this port status with CAS bit is reported and this port can't be used by any device. When CAS bit is set the port should be reset by warm reset. This was not supported by xhci driver. The issue was found when pendrive was connected to suspended platform. The link state of "Compliance Mode" was reported together with CAS bit. This link state was also not supported by xhci and core/hub.c. The CAS bit is defined only for xhci root hub port and it is not supported on regular hubs. The link status is used to force warm reset on port. Make the USB core issue a warm reset when port is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver to report 'compliance mode' when the CAS is set. This force warm reset on the root hub port. This patch should be backported to stable kernels as old as 3.2, that contain the commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When hot reset for USB3 fails, try warm reset." Signed-off-by: Stanislaw Ledwon <staszek.ledwon@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Andiry Xu <andiry.xu@amd.com> Cc: stable@vger.kernel.org
* xhci: Add roothub code to set U1/U2 timeouts.Sarah Sharp2012-05-181-0/+19
| | | | | | | | | | | | | USB 3.0 hubs can be put into a mode where the hub can automatically request that the link go into a deeper link power state after the link has been idle for a specified amount of time. Each of the new USB 3.0 link states (U1 and U2) have their own timeout that can be programmed per port. Change the xHCI roothub emulation code to handle the request to set the U1 and U2 timeouts. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xHCI: keep track of ports being resumed and indicate in hub_status_dataAndiry Xu2012-05-031-10/+12
| | | | | | | | | | | | | | | | | | This commit adds a bit-array to xhci bus_state for keeping track of which ports are undergoing a resume transition. If any of the bits are set when xhci_hub_status_data() is called, the routine will return a non-zero value even if no ports have any status changes pending. This will allow usbcore to handle races between root-hub suspend and port wakeup. This patch should be backported to kernels as old as 3.4, that contain the commit 879d38e6bc36d73b0ac40ec9b0d839fda9fa8b1a "USB: fix race between root-hub suspend and remote wakeup". Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: stable@vger.kernel.org
* USB/xHCI: Enable USB 3.0 hub remote wakeup.Sarah Sharp2012-02-141-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | USB 3.0 hubs have a different remote wakeup policy than USB 2.0 hubs. USB 2.0 hubs, once they have remote wakeup enabled, will always send remote wakes when anything changes on a port. However, USB 3.0 hubs have a per-port remote wake up policy that is off by default. The Set Feature remote wake mask can be changed for any port, enabling remote wakeup for a connect, disconnect, or overcurrent event, much like EHCI and xHCI host controller "wake on" port status bits. The bits are cleared to zero on the initial hub power on, or after the hub has been reset. Without this patch, when a USB 3.0 hub gets suspended, it will not send a remote wakeup on device connect or disconnect. This would show up to the user as "dead ports" unless they ran lsusb -v (since newer versions of lsusb use the sysfs files, rather than sending control transfers). Change the hub driver's suspend method to enable remote wake up for disconnect, connect, and overcurrent for all ports on the hub. Modify the xHCI driver's roothub code to handle that request, and set the "wake on" bits in the port status registers accordingly. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Fix oops caused by more USB2 ports than USB3 ports.Sarah Sharp2012-02-101-1/+1
| | | | | | | | | | | | | | The code to set the device removable bits in the USB 2.0 roothub descriptor was accidentally looking at the USB 3.0 port registers instead of the USB 2.0 registers. This can cause an oops if there are more USB 2.0 registers than USB 3.0 registers. This should be backported to kernels as old as 2.6.39, that contain the commit 4bbb0ace9a3de8392527e3c87926309d541d3b00 "xhci: Return a USB 3.0 hub descriptor for USB3 roothub." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
* xHCI: Adding #define values used for hub descriptorAman Deep2011-11-261-10/+8
| | | | | | | | | | | | | xhci-hub used some numerical values for initialisation of root hub descriptors. #define values are addded in usb 2.0 hub specification file and these values are used for root hub characteristics initialisation. Also use some #defines in places where magic numbers are being used. Signed-off-by: Aman Deep <amandeep3986@gmail.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* usb: fix implicit usage of gfp.h in host/xhci-hub.cPaul Gortmaker2011-10-311-0/+1
| | | | | | | | | | To fix this build error on ARM: drivers/usb/host/xhci-hub.c: In function 'xhci_stop_device': drivers/usb/host/xhci-hub.c:261: error: 'GFP_NOIO' undeclared (first use in this function) make[4]: *** [drivers/usb/host/xhci-hub.o] Error 1 Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* Merge branch 'usb-next' of ↵Linus Torvalds2011-10-251-50/+89
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb * 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (260 commits) usb: renesas_usbhs: fixup inconsistent return from usbhs_pkt_push() usb/isp1760: Allow to optionally trigger low-level chip reset via GPIOLIB. USB: gadget: midi: memory leak in f_midi_bind_config() USB: gadget: midi: fix range check in f_midi_out_open() QE/FHCI: fixed the CONTROL bug usb: renesas_usbhs: tidyup for smatch warnings USB: Fix USB Kconfig dependency problem on 85xx/QoirQ platforms EHCI: workaround for MosChip controller bug usb: gadget: file_storage: fix race on unloading USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers USB: ftdi_sio.c:Fill MSR fields of the ftdi async_icount structure USB: ftdi_sio.c: Fill LSR fields of the ftdi async_icount structure USB: ftdi_sio.c:Fill TX field of the ftdi async_icount structure USB: ftdi_sio.c: Fill the RX field of the ftdi async_icount structure USB: ftdi_sio.c: Basic icount infrastructure for ftdi_sio usb/isp1760: Let OF bindings depend on general CONFIG_OF instead of PPC_OF . USB: ftdi_sio: Support TI/Luminary Micro Stellaris BD-ICDI Board USB: Fix runtime wakeup on OHCI xHCI/USB: Make xHCI driver have a BOS descriptor. usb: gadget: add new usb gadget for ACM and mass storage ...
| * xHCI/USB: Make xHCI driver have a BOS descriptor.Sarah Sharp2011-10-181-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To add USB 3.0 link power management (LPM), we need to know what the U1 and U2 exit latencies are for the xHCI host controller. External USB 3.0 hubs report these values through the SuperSpeed Capabilities descriptor in the BOS descriptor. Make the USB 3.0 roothub for the xHCI host behave like an external hub and return the BOS descriptors. The U1 and U2 exit latencies will vary across each host controller, so we need to dynamically fill those values in by reading the exit latencies out of the xHC registers. Make the roothub code in the USB core handle hub_control() returning the length of the data copied. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xHCI: set USB2 hardware LPMAndiry Xu2011-09-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xHCI: test and clear RWC bitAndiry Xu2011-09-261-6/+16
| | | | | | | | | | | | | | | | Introduce xhci_test_and_clear_bit() to clear RWC bit in PORTSC register. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xHCI: set link stateAndiry Xu2011-09-261-43/+29
| | | | | | | | | | | | | | | | Introduce xhci_set_link_state() to remove redundant codes. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xhci: Rename virt_dev->port to fake_port.Sarah Sharp2011-09-091-1/+1
| | | | | | | | | | | | | | | | | | | | The "port" field in xhci_virt_dev stores the port number associated with one of the two xHCI split roothubs, not the unique port number the xHCI hardware uses. Since we'll need to store the real hardware port number in future patches, rename this field to "fake_port". Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | USB: xhci: Set change bit when warm reset change is set.Greg KH2011-09-191-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, when a USB 3.0 device is disconnected, the Intel Panther Point xHCI host controller will report a link state change with the state set to "SS.Inactive". This causes the xHCI host controller to issue a warm port reset, which doesn't finish before the USB core times out while waiting for it to complete. When the warm port reset does complete, and the xHC gives back a port status change event, the xHCI driver kicks khubd. However, it fails to set the bit indicating there is a change event for that port because the logic in xhci-hub.c doesn't check for the warm port reset bit. After that, the warm port status change bit is never cleared by the USB core, and the xHC stops reporting port status change bits. (The xHCI spec says it shouldn't report more port events until all change bits are cleared.) This means any port changes when a new device is connected will never be reported, and the port will seem "dead" until the xHCI driver is unloaded and reloaded, or the computer is rebooted. Fix this by making the xHCI driver set the port change bit when a warm port reset change bit is set. A better solution would be to make the USB core handle warm port reset in differently, merging the current code with the standard port reset code that does an incremental backoff on the timeout, and tries to complete the port reset two more times before giving up. That more complicated fix will be merged next window, and this fix will be backported to stable. This should be backported to kernels as old as 3.0, since that was the first kernel with commit a11496ebf375 ("xHCI: warm reset support"). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* xHCI: report USB2 port in resuming as suspendAndiry Xu2011-08-091-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a USB2 port initiate a remote wakeup, software shall ensure that resume is signaled for at least 20ms, and then write '0' to the PLS field. According to this, xhci driver do the following things: 1. When receive a remote wakeup event in irq_handler, set the resume_done value as jiffies + 20ms, and modify rh_timer to poll root hub status at that time; 2. When receive a GetPortStatus request, if the jiffies is after the resume_done value, clear the resume signal and resume_done. However, if usb_port_resume() is called before the rh_timer triggered, it will indicate the port as Suspend Cleared and skip the clear resume signal part. The device will fail the usb_get_status request in finish_port_resume(), and usbcore will try a reset-resume instead. Device will work OK after reset-resume, but resume_done value is not cleared in this case, and xhci_bus_suspend() will fail because when it finds a non-zero resume_done value, it will regard the port as resuming and return -EBUSY. This causes issue on some platforms that the system fail to suspend after remote wakeup from suspend by USB2 devices connected to xHCI port. To fix this issue, report the port status as suspend if the resume is signaling less that 20ms, and usb_port_resume() will wait 25ms and check port status again, so xHCI driver can clear the resume signaling and resume_done value. This should be backported to kernels as old as 2.6.37. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
* xHCI: fix port U3 status check conditionAndiry Xu2011-08-091-1/+1
| | | | | | | | | | | | Fix the port U3 status check when Clear PORT_SUSPEND Feature. The port status should be masked with PORT_PLS_MASK to check if it's in U3 state. This should be backported to kernels as old as 2.6.37. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
* xhci: move the common code to a function to get max ports and port arrayhuajun li2011-05-121-39/+27
| | | | | | | | There are several functions using same code to get max ports and port array, this patch moves the common code to a function in order to reuse them easily. Signed-off-by: Huajun Li <huajun.li.lee@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* Merge branch 2.6.39-rc7 into usb-linusGreg Kroah-Hartman2011-05-101-2/+17
|\ | | | | | | | | | | | | This was needed to resolve a conflict in: drivers/usb/host/isp1760-hcd.c Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * xHCI: Clear PLC in xhci_bus_resume()Andiry Xu2011-05-031-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch clears PORT_PLC if xhci_bus_resume() resumes a previous suspended port, because if a port transition from U3 to U0 state, it will report a port link state change, and software should clear the corresponding PLC bit. It also uses hcd->speed to check if a port is a USB2 protocol port. The patch fixes the issue that USB keyboard can not wakeup system from hibernation. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | usbcore: Refine USB3.0 device suspend and resumeAndiry Xu2011-05-021-28/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | In the past, we use USB2.0 request to suspend and resume a USB3.0 device. Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request, instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device suspend/resume comply with USB3.0 specification. This patch fixes the issue that USB3.0 device can not be suspended when connected to a USB3.0 external hub. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | xHCI: report USB3.0 portstatus comply with USB3.0 specificationAndiry Xu2011-05-021-12/+29
| | | | | | | | | | | | | | | | | | | | | | USB3.0 specification has different wPortStatus and wPortChange definitions from USB2.0 specification. Since USB3 root hub and USB2 root hub are split now and USB3 hub only has USB3 protocol ports, we should modify the portstatus and portchange report of USB3 ports to comply with USB3.0 specification. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | xHCI: Set link state supportAndiry Xu2011-05-021-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for Set Port Feature(PORT_LINK_STATE) request. The most significant byte (bits 15..8) of the wIndex field specifies the U state the host software wants to put the link connected to the port into. This request is only valid when the PORT_ENABLE bit is set and the PORT_LINK_STATE should not be above value '5' (Rx.Detect). This request will be later used to replace the set/clear suspend USB3 protocol ports in hub driver. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | xHCI: Clear link state change supportAndiry Xu2011-05-021-0/+5
| | | | | | | | | | | | | | | | This patch adds support for Clear Port Feature(C_PORT_LINK_STATE) request from usbcore. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | xHCI: warm reset supportAndiry Xu2011-05-021-0/+11
| | | | | | | | | | | | | | | | | | | | This patch adds warm reset support to xhci hub control. It handles Set Port Feature(BH_PORT_RESET) and Clear Port Feature (C_BH_PORT_RESET) request from usbcore. Note warm reset is called BH reset some places in USB3.0 specification. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* | xhci: Make xHCI driver endian-safeMatt Evans2011-05-021-9/+9
|/ | | | | | | | | | | | | | | This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol.Sarah Sharp2011-03-131-2/+0
| | | | | | | | | | | | | | | | USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to track whether USB ports had a SuperSpeed device attached. This is a linux-internal symbol that was used when SuperSpeed and non-SuperSpeed devices would show up under the same xHCI roothub. This particular port status is never returned by external USB 3.0 hubs. (Instead they have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed mask.) Now that the xHCI driver registers two roothubs, USB 3.0 devices will only show up under USB 3.0 hubs. Rip out USB_PORT_STAT_SUPER_SPEED and replace it with calls to hub_is_superspeed(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Make roothub functions deal with device removal.Sarah Sharp2011-03-131-0/+16
| | | | | | | | | Return early in the roothub control and status functions if the xHCI host controller is not electrically present in the system (register reads return all "fs"). This issue only shows up when the xHCI driver registers two roothubs and the host controller is removed from the system. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Return a USB 3.0 hub descriptor for USB3 roothub.Sarah Sharp2011-03-131-20/+114
| | | | | | | | | | | | | | | | | | | | Return the correct xHCI roothub descriptor, based on whether the roothub is marked as USB 3.0 or USB 2.0 in usb_hcd->bcdUSB. Fill in DeviceRemovable for the USB 2.0 and USB 3.0 roothub descriptors, using the Device Removable bit in the port status and control registers. xHCI is the first host controller to actually properly set these bits (other hosts say all devices are removable). When userspace asks for a USB 2.0-style hub descriptor for the USB 3.0 roothub, stall the endpoint. This is what real external USB 3.0 hubs do, and we don't want to return a descriptor that userspace didn't ask for. The USB core is already fixed to always ask for USB 3.0-style hub descriptors. Only usbfs (typically lsusb) will ask for the USB 2.0-style hub descriptors. This has already been fixed in usbutils version 0.91, but the kernel needs to deal with older usbutils versions. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Register second xHCI roothub.Sarah Sharp2011-03-131-45/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the xHCI driver to allocate two roothubs. This touches the driver initialization and shutdown paths, roothub emulation code, and port status change event handlers. This is a rather large patch, but it can't be broken up, or it would break git-bisect. Make the xHCI driver register its own PCI probe function. This will call the USB core to create the USB 2.0 roothub, and then create the USB 3.0 roothub. This gets the code for registering a shared roothub out of the USB core, and allows other HCDs later to decide if and how many shared roothubs they want to allocate. Make sure the xHCI's reset method marks the xHCI host controller's primary roothub as the USB 2.0 roothub. This ensures that the high speed bus will be processed first when the PCI device is resumed, and any USB 3.0 devices that have migrated over to high speed will migrate back after being reset. This ensures that USB persist works with these odd devices. The reset method will also mark the xHCI USB2 roothub as having an integrated TT. Like EHCI host controllers with a "rate matching hub" the xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller. It doesn't really have a TT, but we'll lie and say it has an integrated TT. We need to do this because the USB core will reject LS/FS devices under a HS hub without a TT. Other details: ------------- The roothub emulation code is changed to return the correct number of ports for the two roothubs. For the USB 3.0 roothub, it only reports the USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS ports. The code to disable a port now checks the speed of the roothub, and refuses to disable SuperSpeed ports under the USB 3.0 roothub. The code for initializing a new device context must be changed to set the proper roothub port number. Since we've split the xHCI host into two roothubs, we can't just use the port number in the ancestor hub. Instead, we loop through the array of hardware port status register speeds and find the Nth port with a similar speed. The port status change event handler is updated to figure out whether the port that reported the change is a USB 3.0 port, or a non-SuperSpeed port. Once it figures out the port speed, it kicks the proper roothub. The function to find a slot ID based on the port index is updated to take into account that the two roothubs will have over-lapping port indexes. It checks that the virtual device with a matching port index is the same speed as the passed in roothub. There's also changes to the driver initialization and shutdown paths: 1. Make sure that the xhci_hcd pointer is shared across the two usb_hcd structures. The xhci_hcd pointer is allocated and the registers are mapped in when xhci_pci_setup() is called with the primary HCD. When xhci_pci_setup() is called with the non-primary HCD, the xhci_hcd pointer is stored. 2. Make sure to set the sg_tablesize for both usb_hcd structures. Set the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit DMA. (The PCI DMA mask is set from the primary HCD further down in the xhci_pci_setup() function.) 3. Ensure that the host controller doesn't start kicking khubd in response to port status changes before both usb_hcd structures are registered. xhci_run() only starts the xHC running once it has been called with the non-primary roothub. Similarly, the xhci_stop() function only halts the host controller when it is called with the non-primary HCD. Then on the second call, it resets and cleans up the MSI-X irqs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Change xhci_find_slot_id_by_port() API.Sarah Sharp2011-03-131-6/+10
| | | | | | | | | | | | | xhci_find_slot_id_by_port() tries to map the port index to the slot ID for the USB device. In the future, there will be two xHCI roothubs, and their port indices will overlap. Therefore, xhci_find_slot_id_by_port() will need to use information in the roothub's usb_hcd structure to map the port index and roothub speed to the right slot ID. Add a new parameter to xhci_find_slot_id_by_port(), in order to pass in the roothub's usb_hcd structure. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Refactor bus suspend state into a struct.Sarah Sharp2011-03-131-21/+29
| | | | | | | | | | | | | | There are several variables in the xhci_hcd structure that are related to bus suspend and resume state. There are a couple different port status arrays that are accessed by port index. Move those variables into a separate structure, xhci_bus_state. Stash that structure in xhci_hcd. When we have two roothhubs that can be suspended and resumed separately, we can have two xhci_bus_states, and index into the port arrays in each structure with the fake roothub port index (not the real hardware port index). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Index with a port array instead of PORTSC addresses.Sarah Sharp2011-03-131-47/+79
| | | | | | | | | | | | | | | | | | In the upcoming patches, the roothub emulation code will need to return port status and port change buffers based on whether they are called with the xHCI USB 2.0 or USB 3.0 roothub. To facilitate that, make the roothub code index into an array of port addresses with wIndex, rather than calculating the address using the offset and the address of the PORTSC registers. Later we can set the port array to be the array of USB 3.0 port addresses, or the USB 2.0 port addresses, depending on the roothub passed in. Create a temporary (statically sized) port array and fill it in with both USB 3.0 and USB 2.0 port addresses. This is inefficient to do for every roothub call, but this is needed for git bisect compatibility. The temporary port array will be deleted in a subsequent patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* USB 3.0 Hub ChangesJohn Youn2011-03-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the USB core to deal with USB 3.0 hubs. These hubs have a slightly different hub descriptor than USB 2.0 hubs, with a fixed (rather than variable length) size. Change the USB core's hub descriptor to have a union for the last fields that differ. Change the host controller drivers that access those last fields (DeviceRemovable and PortPowerCtrlMask) to use the union. Translate the new version of the hub port status field into the old version that khubd understands. (Note: we need to fix it to translate the roothub's port status once we stop converting it to USB 2.0 hub status internally.) Add new code to handle link state change status. Send out new control messages that are needed for USB 3.0 hubs, like Set Hub Depth. This patch is a modified version of the original patch submitted by John Youn. It's updated to reflect the removal of the "bitmap" #define, and change the hub descriptor accesses of a couple new host controller drivers. Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: "Robert P. J. Day" <rpjday@crashcourse.ca> Cc: Max Vozeler <mvz@vozeler.com> Cc: Tejun Heo <tj@kernel.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Rodolfo Giometti <giometti@linux.it> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Anton Vorontsov <avorontsov@mvista.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Cc: Lothar Wassmann <LW@KARO-electronics.de> Cc: Olav Kongas <ok@artecdesign.ee> Cc: Martin Fuzzey <mfuzzey@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net>
OpenPOWER on IntegriCloud