Cross Reference: /drivers/usb/host/xhci-mem.c

History log of /drivers/usb/host/xhci-mem.c
Revision	Date	Author	Comments (<<< Hide modified files) (Show modified files >>>)
340a3504fd39dad753ba908fb6f894ee81fc3ae2	13-Feb-2012	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Fix encoding for HS bulk/control NAK rate. The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must be encoded as an exponent of two number of microframes. The endpoint descriptor has the NAK rate encoded in number of microframes. We were just copying the value from the endpoint descriptor into the endpoint context interval field, which was not correct. This lead to the VIA host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass storage device. The fix is to use the correct encoding. Refactor the code to convert number of frames to an exponential number of microframes, and make sure we convert the number of microframes in HS bulk and control endpoints to an exponent. This should be back ported to kernels as old as 2.6.31, that contain the commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval" Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Felipe Contreras <felipe.contreras@gmail.com> Suggested-by: Andiry Xu <andiry.xu@amd.com> Cc: stable@vger.kernel.org /drivers/usb/host/xhci-mem.c
1ba6108f5fc02f04784e7206ed08d10805035507	01-Dec-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Remove debugging about ring structure allocation. Debuggers only really care what the xHCI driver sets the ring dequeue pointer to, so make the driver stop babbling about the memory addresses of internal ring structures. This makes wading through the output of allocating and freeing 256 stream rings much easier by reducing the number of output lines per ring from 9 to 1. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
d31c285b3a71cf9056e6a060de41f37780b0af86	03-Nov-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Set slot and ep0 flags for address command. Matt's AsMedia xHCI host controller was responding with a Context Error to an address device command after a configured device reset. Some sequence of events leads both the slot and endpoint zero add flags cleared to zero, which the AsMedia host doesn't like: [ 223.701839] xhci_hcd 0000:03:00.0: Slot ID 1 Input Context: [ 223.701841] xhci_hcd 0000:03:00.0: @ffff880137b25000 (virt) @ffffc000 (dma) 0x000000 - drop flags [ 223.701843] xhci_hcd 0000:03:00.0: @ffff880137b25004 (virt) @ffffc004 (dma) 0x000000 - add flags [ 223.701846] xhci_hcd 0000:03:00.0: @ffff880137b25008 (virt) @ffffc008 (dma) 0x000000 - rsvd2[0] [ 223.701848] xhci_hcd 0000:03:00.0: @ffff880137b2500c (virt) @ffffc00c (dma) 0x000000 - rsvd2[1] [ 223.701850] xhci_hcd 0000:03:00.0: @ffff880137b25010 (virt) @ffffc010 (dma) 0x000000 - rsvd2[2] [ 223.701852] xhci_hcd 0000:03:00.0: @ffff880137b25014 (virt) @ffffc014 (dma) 0x000000 - rsvd2[3] [ 223.701854] xhci_hcd 0000:03:00.0: @ffff880137b25018 (virt) @ffffc018 (dma) 0x000000 - rsvd2[4] [ 223.701857] xhci_hcd 0000:03:00.0: @ffff880137b2501c (virt) @ffffc01c (dma) 0x000000 - rsvd2[5] [ 223.701858] xhci_hcd 0000:03:00.0: Slot Context: [ 223.701860] xhci_hcd 0000:03:00.0: @ffff880137b25020 (virt) @ffffc020 (dma) 0x8400000 - dev_info [ 223.701862] xhci_hcd 0000:03:00.0: @ffff880137b25024 (virt) @ffffc024 (dma) 0x010000 - dev_info2 [ 223.701864] xhci_hcd 0000:03:00.0: @ffff880137b25028 (virt) @ffffc028 (dma) 0x000000 - tt_info [ 223.701866] xhci_hcd 0000:03:00.0: @ffff880137b2502c (virt) @ffffc02c (dma) 0x000000 - dev_state [ 223.701869] xhci_hcd 0000:03:00.0: @ffff880137b25030 (virt) @ffffc030 (dma) 0x000000 - rsvd[0] [ 223.701871] xhci_hcd 0000:03:00.0: @ffff880137b25034 (virt) @ffffc034 (dma) 0x000000 - rsvd[1] [ 223.701873] xhci_hcd 0000:03:00.0: @ffff880137b25038 (virt) @ffffc038 (dma) 0x000000 - rsvd[2] [ 223.701875] xhci_hcd 0000:03:00.0: @ffff880137b2503c (virt) @ffffc03c (dma) 0x000000 - rsvd[3] [ 223.701877] xhci_hcd 0000:03:00.0: Endpoint 00 Context: [ 223.701879] xhci_hcd 0000:03:00.0: @ffff880137b25040 (virt) @ffffc040 (dma) 0x000000 - ep_info [ 223.701881] xhci_hcd 0000:03:00.0: @ffff880137b25044 (virt) @ffffc044 (dma) 0x2000026 - ep_info2 [ 223.701883] xhci_hcd 0000:03:00.0: @ffff880137b25048 (virt) @ffffc048 (dma) 0xffffe8e0 - deq [ 223.701885] xhci_hcd 0000:03:00.0: @ffff880137b25050 (virt) @ffffc050 (dma) 0x000000 - tx_info [ 223.701887] xhci_hcd 0000:03:00.0: @ffff880137b25054 (virt) @ffffc054 (dma) 0x000000 - rsvd[0] [ 223.701889] xhci_hcd 0000:03:00.0: @ffff880137b25058 (virt) @ffffc058 (dma) 0x000000 - rsvd[1] [ 223.701892] xhci_hcd 0000:03:00.0: @ffff880137b2505c (virt) @ffffc05c (dma) 0x000000 - rsvd[2] ... [ 223.701927] xhci_hcd 0000:03:00.0: // Ding dong! [ 223.701992] xhci_hcd 0000:03:00.0: Setup ERROR: address device command for slot 1. The xHCI spec says that both flags must be set to one for the Address Device command. When the device is first enumerated, xhci_setup_addressable_virt_dev() does set those flags. However, when the device is addressed after it has been reset in the configured state, xhci_setup_addressable_virt_dev() is not called, and xhci_copy_ep0_dequeue_into_input_ctx() is called instead. That function relies on the flags being set up by previous commands, which apparently isn't a good assumption. Move the setting of the flags into the common parent function. This should be queued for stable kernels as old as 2.6.35, since that was the first introduction of xhci_copy_ep0_dequeue_into_input_ctx. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Matt <mdm@iinet.net.au> Cc: stable@vger.kernel.org /drivers/usb/host/xhci-mem.c
22d45f01a836c2f5826b8b4b9e029e5f79afec57	23-Sep-2011	Sebastian Andrzej Siewior <bigeasy@linutronix.de>	usb/xhci: replace pci__consistent() with dma__coherent() pci__consistent() calls dma__coherent() with GFP_ATOMIC and requires pci_dev struct. This is a preparion for later where we no longer have the pci struct around. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
7e393a834b41001174a8fb3ae3bc23a749467760	23-Sep-2011	Andiry Xu <andiry.xu@amd.com>	xHCI: AMD isoc link TRB chain bit quirk Setting the chain (CH) bit in the link TRB of isochronous transfer rings is required by AMD 0.96 xHCI host controller to successfully transverse multi-TRB TD that span through different memory segments. When a Missed Service Error event occurs, if the chain bit is not set in the link TRB and the host skips TDs which just across a link TRB, the host may falsely recognize the link TRB as a normal TRB. You can see this may cause big trouble - the host does not jump to the right address which is pointed by the link TRB, but continue fetching the memory which is after the link TRB address, which may not even belong to the host, and the result cannot be predicted. This causes some big problems. Without the former patch I sent: "xHCI: prevent infinite loop when processing MSE event", the system may hang. With that patch applied, system does not hang, but the host still access wrong memory address and isoc transfer will fail. With this patch, isochronous transfer works as expected. This patch should be applied to kernels as old as 2.6.36, which was when the first isochronous support was added for the xHCI host controller. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
9574323c39d1f8359a04843075d89c9f32d8b7e6	23-Sep-2011	Andiry Xu <andiry.xu@amd.com>	xHCI: test USB2 software LPM This patch tests USB2 software LPM for a USB2 LPM-capable device. When a lpm-capable device is addressed, if the host also supports software LPM, apply a test by putting the device into L1 state and resume it to see if the device can do L1 suspend/resume successfully. If the device fails to enter L1 or resume from L1 state, it may not function normally and usbcore may disconnect and re-enumerate it. In this case, store the device's Vid and Pid information, make sure the host will not test LPM for it twice. The test result is per device/host. Some devices claim to be lpm-capable, but fail to enter L1 or resume. So the test is necessary. The xHCI 1.0 errata has modified the USB2.0 LPM implementation. It redefines the HIRD field to BESL, and adds another register Port Hardware LPM Control (PORTHLPMC). However, this should not affect the LPM behavior on xHC which does not implement 1.0 errata. USB2.0 LPM errata defines a new bit BESL in the device's USB 2.0 extension descriptor. If the device reports it uses BESL, driver should use BESL instead of HIRD for it. 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> /drivers/usb/host/xhci-mem.c
fc71ff7583b14347fa1cb592b698f088ecff36e3	23-Sep-2011	Andiry Xu <andiry.xu@amd.com>	xHCI: Check host USB2 LPM capability Check the host's USB2 LPM capability. USB2 software LPM support is optional for xHCI 0.96 hosts. xHCI 1.0 hosts should support software LPM, and may support hardware LPM. 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> /drivers/usb/host/xhci-mem.c
27ccaaa507f6211afc277786d461d1884951d038	20-Sep-2011	Kautuk Consul <consul.kautuk@gmail.com>	xhci-mem.c: xhci_segment_free: No need for checking seg argument The seg argument to xhci_segment_free is never passed as NULL, so no need to check for this in xhci_segment_free. Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
0e6c7f746ea99089fb3263709075c20485a479ae	20-Sep-2011	Kautuk Consul <consul.kautuk@gmail.com>	xhci-mem.c: Check for ring->first_seg != NULL There are 2 situations wherein the xhci_ring* might not get freed: - When xhci_ring_alloc() -> xhci_segment_alloc() returns NULL and we goto the fail: label in xhci_ring_alloc. In this case, the ring will not get kfreed. - When the num_segs argument to xhci_ring_alloc is passed as 0 and we try to free the rung after that. ( This doesn't really happen as of now in the code but we seem to be entertaining num_segs=0 in xhci_ring_alloc ) This should be backported to kernels as old as 2.6.31. Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
170c026347c867a71e27713b98c58b266146c468	14-Sep-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Fix mult base in endpoint bandwidth info. The "Mult" bits in the SuperSpeed Endpoint Companion Descriptor are zero-based, and the xHCI host controller wants them to be zero-based in the input context. However, for the bandwidth math, we want them to be one-based. Fix this. Fix the documentation about the endpoint bandwidth mult variable in the xhci.h file, which says it is zero-based. Also fix the documentation about num_packets, which is also one-based, not zero-based. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
2ffdea25f054439c31c24b248faa647685280571	02-Sep-2011	Andiry Xu <andiry.xu@amd.com>	xHCI: refine td allocation In xhci_urb_enqueue(), allocate a block of memory for all the TDs instead of allocating memory for each of them separately. This reduces the number of kzalloc calling when an isochronous usb is submitted. 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> /drivers/usb/host/xhci-mem.c
2e27980e6eb78114c4ecbaad1ba71836e3887d18	02-Sep-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Track interval bandwidth tables per port/TT. In order to update the root port or TT's bandwidth interval table, we will need to keep track of a list of endpoints, per interval. That way we can easily know the new largest max packet size when we have to remove an endpoint. Add an endpoint list for each root port or TT structure, sorted by endpoint max packet size. Insert new endpoints into the list such that the head of the list always has the endpoint with the greatest max packet size. Only insert endpoints and update the interval table with new information when those endpoints are periodic. Make sure to update the number of active TTs when we add or drop periodic endpoints. A TT is only considered active if it has one or more periodic endpoints attached (control and bulk are best effort, and counted in the 20% reserved on the high speed bus). If the number of active endpoints for a TT was zero, and it's now non-zero, increment the number of active TTs for the rootport. If the number of active endpoints was non-zero, and it's now zero, decrement the number of active TTs. We have to be careful when we're checking the bandwidth for a new configuration/alt setting. If we don't have enough bandwidth, we need to be able to "roll back" the bandwidth information stored in the endpoint and the root port/TT interval bandwidth table. We can't just create a copy of the interval bandwidth table, modify it, and check the bandwidth with the copy because we have lists of endpoints and entries can't be on more than one list. Instead, we copy the old endpoint bandwidth information, and use it to revert the interval table when the bandwidth check fails. We don't check the bandwidth after endpoints are dropped from the interval table when a device is reset or freed after a disconnect, because having endpoints use less bandwidth should not push the bandwidth usage over the limits. Besides which, we can't fail a device disconnect. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
9af5d71d8e1fc404ad2ac1b568dafa1a2f9b3be2	02-Sep-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Store endpoint bandwidth information. In the upcoming patches, we'll use some stored endpoint information to make software keep track of the worst-case bandwidth schedule. We need to store several variables associated with each periodic endpoint: - the type of endpoint - Max Packet Size - Mult - Max ESIT payload - Max Burst Size (aka number of packets, stored in one-based form) - the endpoint interval (normalized to powers of 2 microframes) All this information is available to the hardware, and stored in its device output context. However, we need to ensure that the new information is stored before the xHCI driver drops the xhci->lock to wait on the Configure Endpoint command, so that another driver requesting a configuration or alt setting change will see the update. The Configure Endpoint command will never fail on the hardware that needs this software bandwidth checking (assuming the slot is enabled and the flags are set properly), so updating the endpoint info before the command completes should be fine. Until we add in the bandwidth checking code, just update the endpoint information after the Configure Endpoint command completes, and after a Reset Device command completes. Don't bother to clear the endpoint bandwidth info when a device is being freed, since the xhci_virt_ep is just going to be freed anyway. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
839c817ce67178ca3c7c7ad534c571bba1e69ebe	02-Sep-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Store information about roothubs and TTs. For upcoming patches, we need to keep information about the bandwidth domains under the xHCI host. Each root port is a separate primary bandwidth domain, and each high speed hub's TT (and potentially each port on a multi-TT hub) is a secondary bandwidth domain. If the table were in text form, it would look a bit like this: EP Interval Sum of Number Largest Max Max Packet of Packets Packet Size Overhead 0 N mps overhead ... 15 N mps overhead Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol overhead, etc) for all the endpoints in this interval. Devices with different speeds have different max packet overhead. For example, if there is a low speed and a full speed endpoint that both have an interval of 3, we would use the higher overhead (the low speed overhead). Interval 0 is a bit special, since we really just want to know the sum of the max ESIT payloads instead of the largest max packet size. That's stored in the interval0_esit_payload variable. For root ports, we also need to keep track of the number of active TTs. For each root port, and each TT under a root port, store some information about the bandwidth consumption. Dynamically allocate an array of root port bandwidth information for the number of root ports on the xHCI host. Each root port stores a list of TTs under the root port. A single TT hub only has one entry in the list, but a multi-TT hub will have an entry per port. When the USB core says that a USB device is a hub, create one or more entries in the root port TT list for the hub. When a device is deleted, and it is a hub, search through the root port TT list and delete all TT entries for the hub. Keep track of which TT entry is associated with a device under a TT. LS/FS devices attached directly to the root port will have usb_device->tt set to the roothub. Ignore that, and treat it like a primary bandwidth domain, since there isn't really a high speed bus between the roothub and the host. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
66381755442189bbeb15f1a51b1e0059327d84ed	02-Sep-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Store the "real" root port number. Since the xHCI driver now has split USB2/USB3 roothubs, devices under each roothub can have duplicate "fake" port numbers. For the next set of patches, we need to keep track of the "real" port number that the xHCI host uses to index into the port status arrays. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
fe30182c2553f491e5dc12074c8e52163d3bfbc7	02-Sep-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Rename virt_dev->port to fake_port. 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> /drivers/usb/host/xhci-mem.c
29cc88979a8818cd8c5019426e945aed118b400e	23-Aug-2011	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>	USB: use usb_endpoint_maxp() instead of le16_to_cpu() Now ${LINUX}/drivers/usb/* can use usb_endpoint_maxp(desc) to get maximum packet size instead of le16_to_cpu(desc->wMaxPacketSize). This patch fix it up Cc: Armin Fuerst <fuerst@in.tum.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: Johannes Erdfelt <johannes@erdfelt.com> Cc: Vojtech Pavlik <vojtech@suse.cz> Cc: Oliver Neukum <oliver@neukum.name> Cc: David Kubicek <dave@awk.cz> Cc: Johan Hovold <jhovold@gmail.com> Cc: Brad Hards <bhards@bigpond.net.au> Acked-by: Felipe Balbi <balbi@ti.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Thomas Dahlmann <dahlmann.thomas@arcor.de> Cc: David Brownell <david-b@pacbell.net> Cc: David Lopo <dlopo@chipidea.mips.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Michal Nazarewicz <m.nazarewicz@samsung.com> Cc: Xie Xiaobo <X.Xie@freescale.com> Cc: Li Yang <leoli@freescale.com> Cc: Jiang Bo <tanya.jiang@freescale.com> Cc: Yuan-hsin Chen <yhchen@faraday-tech.com> Cc: Darius Augulis <augulis.darius@gmail.com> Cc: Xiaochen Shen <xiaochen.shen@intel.com> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: OKI SEMICONDUCTOR, <toshiharu-linux@dsn.okisemi.com> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Cc: Ben Dooks <ben@simtec.co.uk> Cc: Thomas Abraham <thomas.ab@samsung.com> Cc: Herbert Pötzl <herbert@13thfloor.at> Cc: Arnaud Patard <arnaud.patard@rtp-net.org> Cc: Roman Weissgaerber <weissg@vienna.at> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: Florian Floe Echtler <echtler@fs.tum.de> Cc: Christian Lucht <lucht@codemercs.com> Cc: Juergen Stuber <starblue@sourceforge.net> Cc: Georges Toth <g.toth@e-biz.lu> Cc: Bill Ryder <bryder@sgi.com> Cc: Kuba Ober <kuba@mareimbrium.org> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
f549953c15deab4c54708b39af86d4edecc6cddc	26-Jul-2011	Linus Torvalds <torvalds@linux-foundation.org>	Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 * 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (115 commits) EHCI: fix direction handling for interrupt data toggles USB: serial: add IDs for WinChipHead USB->RS232 adapter USB: OHCI: fix another regression for NVIDIA controllers usb: gadget: m66592-udc: add pullup function usb: gadget: m66592-udc: add function for external controller usb: gadget: r8a66597-udc: add pullup function usb: renesas_usbhs: support multi driver usb: renesas_usbhs: inaccessible pipe is not an error usb: renesas_usbhs: care buff alignment when dma handler USB: PL2303: correctly handle baudrates above 115200 usb: r8a66597-hcd: fixup USB_PORT_STAT_C_SUSPEND shift usb: renesas_usbhs: compile/config are rescued usb: renesas_usbhs: fixup comment-out usb: update email address in ohci-sh and r8a66597-hcd usb: r8a66597-hcd: add function for external controller EHCI: only power off port if over-current is active USB: mon: Allow to use usbmon without debugfs USB: EHCI: go back to using the system clock for QH unlinks ehci: add pci quirk for Ordissimo and RM Slate 100 too ehci: refactor pci quirk to use standard dmi_check_system method ... Fix up trivial conflicts in Documentation/feature-removal-schedule.txt
d23336329fa4c157ed6256d4279a73b87486a1b6	06-Jun-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Don't warn about zeroed bMaxBurst descriptor field. The USB 3.0 specification says that the bMaxBurst field in the SuperSpeed Endpoint Companion descriptor is supposed to indicate how many packets a SS device can handle before it needs to wait for an explicit handshake from the host controller. A zero value means the device can only handle one packet before it needs a handshake. Remove a warning in the xHCI driver that implies this is an invalid value. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
dcc854579059ff9633db4dc41c681371d22f794e	14-Jun-2011	Greg Kroah-Hartman <gregkh@suse.de>	Merge 3.0-rc2 into usb-linus as it's needed by some USB patches Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cd3c18ba2fac14b34d03cae111f215009735ea06	31-May-2011	Dmitry Torokhov <dtor@vmware.com>	USB: xhci - fix interval calculation for FS isoc endpoints Full-speed isoc endpoints specify interval in exponent based form in frames, not microframes, so we need to adjust accordingly. NEC xHCI host controllers will return an error code of 0x11 if a full speed isochronous endpoint is added with the Interval field set to something less than 3 (2^3 = 8 microframes, or one frame). It is impossible for a full speed device to have an interval smaller than one frame. This was always an issue in the xHCI driver, but commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()" removed the clamping of the minimum value in the Interval field, which revealed this bug. This needs to be backported to stable kernels back to 2.6.31. Reported-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org /drivers/usb/host/xhci-mem.c
f5960b698eb50a39fce1a066dc19a6a5a1148e16	01-Jun-2011	Matt Evans <matt@ozlabs.org>	xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
30f89ca021c3e584b61bc5a14eede89f74b2e826	16-May-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Fix memory leak in ring cache deallocation. When an endpoint ring is freed, it is either cached in a per-device ring cache, or simply freed if the ring cache is full. If the ring was added to the cache, then virt_dev->num_rings_cached is incremented. The cache is designed to hold up to 31 endpoint rings, in array indexes 0 to 30. When the device is freed (when the slot was disabled), xhci_free_virt_device() is called, it would free the cached rings in array indexes 0 to virt_dev->num_rings_cached. Unfortunately, the original code in xhci_free_or_cache_endpoint_ring() would put the first entry into the ring cache in array index 1, instead of array index 0. This was caused by the second assignment to rings_cached: rings_cached = virt_dev->num_rings_cached; if (rings_cached < XHCI_MAX_RINGS_CACHED) { virt_dev->num_rings_cached++; rings_cached = virt_dev->num_rings_cached; virt_dev->ring_cache[rings_cached] = virt_dev->eps[ep_index].ring; This meant that when the device was freed, cached rings with indexes 0 to N would be freed, and the last cached ring in index N+1 would not be freed. When the driver was unloaded, this caused interesting messages like: xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy This should be queued to stable kernels back to 2.6.33. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org /drivers/usb/host/xhci-mem.c
b513d44751bfb609a3c20463f764c8ce822d63e9	13-May-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Fix full speed bInterval encoding. Dmitry's patch dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval() introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints' bInterval must be decoded as an exponent to a power of two (e.g. interval = 2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't use exponents, and the interval in frames is encoded straight into bInterval. Dmitry's patch was supposed to fix up the full speed isochronous to parse bInterval as an exponent, but instead it changed the interrupt endpoint bInterval decoding. The isochronous endpoint encoding was the same. This caused full speed devices with interrupt endpoints (including mice, hubs, and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers: [ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000 [ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000 ... [ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11. [ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000 When the interrupt endpoint was added and a Configure Endpoint command was issued to the host, the host controller would return a very odd error message (0x11 means "Slot Not Enabled", which isn't true because the slot was enabled). Probably the host controller was getting very confused with the bad encoding. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Dmitry Torokhov <dtor@vmware.com> Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com> Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> /drivers/usb/host/xhci-mem.c
7b1fc2ea8a5fbf9487d83865456cff77d0249ea9	05-May-2011	Andiry Xu <andiry.xu@amd.com>	xHCI 1.0: Isoch endpoint CErr field set xHCI 1.0 specification specifies that CErr does not apply to Isoch endpoints and shall be set to '0' for Isoch endpoints. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
51eb01a746089f2c3d9b87f870353772d2fb4c37	05-May-2011	Andiry Xu <andiry.xu@amd.com>	xHCI 1.0: Control endpoint average TRB length field set xHCI 1.0 specification indicates that software should set Average TRB Length to '8' for control endpoints. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
64b3c304bed25388fed48dbdc098dfcad7063d9c	11-Apr-2011	Sebastian Andrzej Siewior <bigeasy@linutronix.de>	usb/ch9: use proper endianess for wBytesPerInterval while going through Tatyana's changes for the gadget framework I noticed that this type is not defined as __le16. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
28ccd2962c66556d7037b2d9f1c11cdcd3b805d5	29-Mar-2011	Matt Evans <matt@ozlabs.org>	xhci: Make xHCI driver endian-safe 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> /drivers/usb/host/xhci-mem.c
dfa49c4ad120a784ef1ff0717168aa79f55a483a	24-Mar-2011	Dmitry Torokhov <dtor@vmware.com>	USB: xhci - fix math in xhci_get_endpoint_interval() When parsing exponent-expressed intervals we subtract 1 from the value and then expect it to match with original + 1, which is highly unlikely, and we end with frequent spew: usb 3-4: ep 0x83 - rounding interval to 512 microframes Also, parsing interval for fullspeed isochronous endpoints was incorrect - according to USB spec they use exponent-based intervals (but xHCI spec claims frame-based intervals). I trust USB spec more, especially since USB core agrees with it. This should be queued for stable kernels back to 2.6.31. Reviewed-by: Micah Elizabeth Scott <micah@vmware.com> Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org /drivers/usb/host/xhci-mem.c
575688e1e5f462c44ddd608ce3ec9f38b64c3c0d	20-Mar-2011	Dmitry Torokhov <dtor@vmware.com>	USB: xhci - remove excessive 'inline' markings Remove 'inline' markings from file-local functions and let compiler do its job and inline what makes sense for given architecture. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
22e0487047567252d5677ff35766cd884375efc2	17-Mar-2011	Dan Carpenter <error27@gmail.com>	USB: xhci: unsigned char never equals -1 There were some places that compared port_speed == -1 where port_speed is a u8. This doesn't work unless we cast the -1 to u8. Some places did it correctly. Instead of using -1 directly, I've created a DUPLICATE_ENTRY define which does the cast and is more descriptive as well. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
971f115a50afbe409825c9f3399d5a3b9aca4381	16-Mar-2011	Linus Torvalds <torvalds@linux-foundation.org>	Merge branch 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6 * 'usb-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6: (172 commits) USB: Add support for SuperSpeed isoc endpoints xhci: Clean up cycle bit math used during stalls. xhci: Fix cycle bit calculation during stall handling. xhci: Update internal dequeue pointers after stalls. USB: Disable auto-suspend for USB 3.0 hubs. USB: Remove bogus USB_PORT_STAT_SUPER_SPEED symbol. xhci: Return canceled URBs immediately when host is halted. xhci: Fixes for suspend/resume of shared HCDs. xhci: Fix re-init on power loss after resume. xhci: Make roothub functions deal with device removal. xhci: Limit roothub ports to 15 USB3 & 31 USB2 ports. xhci: Return a USB 3.0 hub descriptor for USB3 roothub. xhci: Register second xHCI roothub. xhci: Change xhci_find_slot_id_by_port() API. xhci: Refactor bus suspend state into a struct. xhci: Index with a port array instead of PORTSC addresses. USB: Set usb_hcd->state and flags for shared roothubs. usb: Make core allocate resources per PCI-device. usb: Store bus type in usb_hcd, not in driver flags. usb: Change usb_hcd->bandwidth_mutex to a pointer. ...
d30b2a208108a0b0fdeae7006b8824d9be16ca96	23-Nov-2010	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Limit roothub ports to 15 USB3 & 31 USB2 ports. The USB core allocates a USB 2.0 roothub descriptor that has room for 31 (USB_MAXCHILDREN) ports' worth of DeviceRemovable and PortPwrCtrlMask fields. Limit the number of USB 2.0 roothub ports accordingly. I don't expect to run into this limitation ever, but this prevents a buffer overflow issue in the roothub descriptor filling code. Similarly, a USB 3.0 hub can only have 15 downstream ports, so limit the USB 3.0 roothub to 15 USB 3.0 ports. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
f6ff0ac878eb420011fa2448851dd48c3a7e7b31	16-Dec-2010	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Register second xHCI roothub. 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> /drivers/usb/host/xhci-mem.c
20b67cf51fa606442bb343afad0ee1a393a6afb3	15-Dec-2010	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Refactor bus suspend state into a struct. 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> /drivers/usb/host/xhci-mem.c
aa1b13efb7cfa9f7bf4942c1e858463e335c9500	03-Mar-2011	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Modify check for TT info. Commit d199c96d by Alan Stern ensured that low speed and full speed devices below a high speed hub without a transaction translator (TT) would never get enumerated. Simplify the check for a TT in the xHCI virtual device allocation to only check if the usb_device references a parent's TT. Make sure not to set the TT information on LS/FS devices directly connected to the roothub. The xHCI host doesn't really have a TT, and the host will throw an error when those virtual device TT fields are set for a device connected to the roothub. We need this check because the xHCI driver will shortly register two roothubs: a USB 2.0 roothub and a USB 3.0 roothub. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
1d5810b6923c76fc95e52d9d3491c91824c2f075	09-Dec-2010	Sarah Sharp <sarah.a.sharp@linux.intel.com>	xhci: Rework port suspend structures for limited ports. 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> /drivers/usb/host/xhci-mem.c
8212a49d1c1e53ad2bc3176b983a2483b48fd989	08-Feb-2011	Dmitry Torokhov <dtor@vmware.com>	USB: xhci: mark local functions as static Functions that are not used outsde of the module they are defined should be marked as static. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
c50a00f8feba42c5bccff47e052e4cb0c95dcd2b	09-Feb-2011	Dmitry Torokhov <dtor@vmware.com>	USB: xhci: fix couple sparse annotations There is no point in casting to (void ) when setting up xhci->ir_set as it only makes us lose __iomem annotation and makes sparse unhappy. OTOH we do need to cast to (void ) when calculating xhci->dba from offset, but since it is IO memory we need to annotate it as such. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c
09ece30e06b19994e6f3d260e5c4be18dce22714	09-Feb-2011	Dmitry Torokhov <dtor@vmware.com>	USB: xhci: rework xhci_print_ir_set() to get ir set from xhci itself xhci->ir_set points to __iomem region, but xhci_print_ir_set accepts plain struct xhci_intr_reg * causing multiple sparse warning at call sites and inside the fucntion when we try to read that memory. Instead of adding __iomem qualifier to the argument let's rework the function so it itself gets needed register set from xhci and prints it. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> /drivers/usb/host/xhci-mem.c