summaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/xhci-hub.c
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* xhci: Remove references to HC_STATE_RUNNING.Sarah Sharp2011-03-131-1/+0
| | | | | | | | | | | The USB core will set hcd->state to HC_STATE_RUNNING before calling xhci_run, so there's no point in setting it twice. The USB core also doesn't pay attention to HC_STATE_RUNNING on the resume path anymore; it uses HCD_RH_RUNNING(), which looks at hcd->flags & (1U << HCD_FLAG_RH_RUNNING. Therefore, it's safe to remove the state set in xhci_bus_resume(). Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Rename variables and reduce register reads.Sarah Sharp2011-03-131-19/+22
| | | | | | | | | | | The xhci_bus_suspend() and xhci_bus_resume() functions are a bit hard to read, because they have an ambiguously named variable "port". Rename it to "port_index". Introduce a new temporary variable, "max_ports" that holds the maximum number of roothub ports the host controller supports. This will reduce the number of register reads, and make it easy to change the maximum number of ports when there are two roothubs. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
* xhci: Rework port suspend structures for limited ports.Sarah Sharp2011-03-131-18/+10
| | | | | | | | | | | | | | | | | | | | | | The USB core only allows up to 31 (USB_MAXCHILDREN) ports under a roothub. The xHCI driver keeps track of which ports are suspended, which ports have a suspend change bit set, and what time the port will be done resuming. It keeps track of the first two by setting a bit in a u32 variable, suspended_ports or port_c_suspend. The xHCI driver currently assumes we can have up to 256 ports under a roothub, so it allocates an array of 8 u32 variables for both suspended_ports and port_c_suspend. It also allocates a 256-element array to keep track of when the ports will be done resuming. Since we can only have 31 roothub ports, we only need to use one u32 for each of the suspend state and change variables. We simplify the bit math that's trying to index into those arrays and set the correct bit, if we assume wIndex never exceeds 30. (wIndex is zero-based after it's decremented from the value passed in from the USB core.) Finally, we change the resume_done array to only hold 31 elements. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com>
* USB: Remove bitmap #define from hcd.hSarah Sharp2011-03-131-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using a #define to redefine a common variable name is a bad thing, especially when the #define is in a header. include/linux/usb/hcd.h redefined bitmap to DeviceRemovable to avoid typing a long field in the hub descriptor. This has unintended side effects for files like drivers/usb/core/devio.c that include that file, since another header included after hcd.h has different variables named bitmap. Remove the bitmap #define and replace instances of it in the host controller code. Cleanup the spaces around function calls and square brackets while we're at it. 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>
* xhci: Don't let the USB core disable SuperSpeed ports.Sarah Sharp2010-11-191-0/+7
| | | | | | | | | | | | | | | | | Disabling SuperSpeed ports is a Very Bad Thing (TM). It disables SuperSpeed terminations, which means that devices will never connect at SuperSpeed on that port. For USB 2.0/1.1 ports, disabling the port meant that the USB core could always get a connect status change later. That's not true with USB 3.0 ports. Do not let the USB core disable SuperSpeed ports. We can't rely on the device speed in the port status registers, since that isn't valid until there's a USB device connected to the port. Instead, we use the port speed array that's created from the Extended Capabilities registers. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Don Zickus <dzickus@redhat.com> Cc: stable@kernel.org
* usb: Fix linker errors with CONFIG_PM=nSarah Sharp2010-10-221-6/+1
| | | | | | | | | | | | | Fix these linker errors when CONFIG_PM=n: ERROR: "xhci_bus_resume" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "xhci_bus_suspend" [drivers/usb/host/xhci-hcd.ko] undefined! Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xHCI: bus power management implementationAndiry Xu2010-10-221-0/+188
| | | | | | | | | | | | | | | | This patch implements xHCI bus suspend/resume function hook. In the patch it goes through all the ports and suspend/resume the ports if needed. If any port is in remote wakeup, abort bus suspend as what ehci/ohci do. Signed-off-by: Libin Yang <libin.yang@amd.com> Signed-off-by: Crane Cai <crane.cai@amd.com> 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>
* USB: xHCI: port remote wakeup implementationAndiry Xu2010-10-221-5/+39
| | | | | | | | | | | | | | | | | | | | This commit implements port remote wakeup. When a port is in U3 state and resume signaling is detected from a device, the port transitions to the Resume state, and the xHC generates a Port Status Change Event. For USB3 port, software write a '0' to the PLS field to complete the resume signaling. For USB2 port, the resume should be signaling for at least 20ms, irq handler set a timer for port remote wakeup, and then finishes process in hub_control GetPortStatus. Some codes are borrowed from EHCI code. 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>
* USB: xHCI: port power management implementationAndiry Xu2010-10-221-1/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add software trigger USB device suspend resume function hook. Do port suspend & resume in terms of xHCI spec. Port Suspend: Stop all endpoints via Stop Endpoint Command with Suspend (SP) flag set. Place individual ports into suspend mode by writing '3' for Port Link State (PLS) field into PORTSC register. This can only be done when the port is in Enabled state. When writing, the Port Link State Write Strobe (LWS) bit shall be set to '1'. Allocate an xhci_command and stash it in xhci_virt_device to wait completion for the last Stop Endpoint Command. Use the Suspend bit in TRB to indicate the Stop Endpoint Command is for port suspend. Based on Sarah's suggestion. Port Resume: Write '0' in PLS field, device will transition to running state. Ring an endpoints' doorbell to restart it. Ref: USB device remote wake need another patch to implement. For details of how USB subsystem do power management, please see: Documentation/usb/power-management.txt Signed-off-by: Crane Cai <crane.cai@amd.com> Signed-off-by: Libin Yang <libin.yang@amd.com> 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>
* USB: xhci: Remove the arbitrary limit of 15 xHCI portsWilliam Gulland2010-05-201-12/+3
| | | | | | | | | | Our virtual xHCI device can have as many ports as we like - I've tested this patch with 31. Signed-off-by: William Gulland <wgulland@vmware.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: straighten out port feature vs. port status usageAlan Stern2010-05-201-8/+8
| | | | | | | | | | | | | | | This patch (as1349b) clears up the confusion in many USB host controller drivers between port features and port statuses. In mosty cases it's true that the status bit is in the position given by the corresponding feature value, but that's not always true and it's not guaranteed in the USB spec. There's no functional change, just replacing expressions of the form (1 << USB_PORT_FEAT_x) with USB_PORT_STAT_x, which has the same value. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: remove bogus USB_PORT_FEAT_*_SPEED symbolsAlan Stern2010-05-201-4/+4
| | | | | | | | | | | | | | | | | This patch (as1348) removes the bogus USB_PORT_FEAT_{HIGHSPEED,SUPERSPEED} symbols from ch11.h. No such features are defined by the USB spec. (There is a PORT_LOWSPEED feature, but the spec doesn't mention it except to say that host software should never use it.) The speed indicators are port statuses, not port features. As a temporary workaround for the xhci-hcd driver, a fictional USB_PORT_STAT_SUPER_SPEED symbol is added. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci: Allow roothub ports to be disabled.Sarah Sharp2010-03-021-0/+18
| | | | | | | | | | | | Add the hub emulation code to allow ports on an xHCI root hub to be disabled. Add the code to clear the port enabled/disabled bit, and clear the port enabled/disabled change bit. Like EHCI, the port cannot be enabled by setting the port enabled/disabled bit. Instead, a port is enabled by the host controller after a reset. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci: Refactor code to clear port change bits.Sarah Sharp2010-03-021-15/+32
| | | | | | | | | | | | | Refactor the code to clear the port change bits in the port status register. All port status change bits are write one to clear. Remove a redundant port status read that was supposed to unblock any posted writes. We read the port after the write to get the updated status for debugging, so the port read after that is unnecessary. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* USB: xhci: Root hub support.Sarah Sharp2009-06-151-0/+308
Add functionality for getting port status and hub descriptor for xHCI root hubs. This is WIP because the USB 3.0 hub descriptor is different from the USB 2.0 hub descriptor. For now, we lie about the root hub descriptor because the changes won't effect how the core talks to the root hub. Later we will need to add the USB 3.0 hub descriptor for real hubs, and this code might change. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
OpenPOWER on IntegriCloud