summaryrefslogtreecommitdiff
path: root/drivers/usb/host/xhci-mem.c
AgeCommit message (Collapse)Author
2013-08-18Merge 3.11-rc6 into usb-nextGreg Kroah-Hartman
We want these USB fixes in this branch as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-13xhci: trace debug statements related to ring expansionXenia Ragiadakou
This patch defines a new trace event, which is called xhci_dbg_ring_expansion and belongs to the event class xhci_log_msg, and adds tracepoints that trace the debug messages associated with the expansion of endpoint ring when there is not enough space allocated to hold all pending TRBs. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-13xhci: trace debug messages related to driver initialization and unloadXenia Ragiadakou
This patch defines a new trace event, which is called xhci_dbg_init and belongs to the event class xhci_log_msg, and adds tracepoints that trace the debug statements in the functions used to start and stop the xhci-hcd driver. Also, it removes an unnecessary cast of variable val to unsigned int in xhci_mem_init(), since val is already declared as unsigned int. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-13xhci: add trace for debug messages related to changing contextsXenia Ragiadakou
This patch defines a new trace event, which is called xhci_dbg_context_change and belongs in the event class xhci_log_msg, and adds tracepoints for tracing the debug messages related to context updates performed with Configure Endpoint and Evaluate Context commands. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-13xhci: remove CONFIG_USB_XHCI_HCD_DEBUGGING and unused codeXenia Ragiadakou
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable verbose debugging output for the xHCI host controller driver. In the current version of the xhci-hcd driver, this option must be turned on, in order for the debugging log messages to be displayed, and users may need to recompile the linux kernel to obtain debugging information that will help them track down problems. This patch removes the above debug option to enable debugging log messages at all times. The aim of this is to rely on the debugfs and the dynamic debugging feature for fine-grained management of debugging messages and to not force users to set the debug config option and compile the linux kernel in order to have access in that information. This patch, also, removes the XHCI_DEBUG symbol and the functions dma_to_stream_ring(), xhci_test_radix_tree() and xhci_event_ring_work() that are not useful anymore. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-07-31usb: xhci: add missing dma-mapping.h includesJames Hogan
A randconfig build hit the following build errors because xhci.c and xhci-mem.c use dma mapping functions but don't include <linux/dma-mapping.h>. Add the missing includes to fix the build errors. drivers/usb/host/xhci.c In function 'xhci_gen_setup': drivers/usb/host/xhci.c +4872 : error: implicit declaration of function 'dma_set_mask' drivers/usb/host/xhci.c +4872 : error: implicit declaration of function 'DMA_BIT_MASK' drivers/usb/host/xhci-mem.c In function 'xhci_free_stream_ctx': drivers/usb/host/xhci-mem.c +435 : error: implicit declaration of function 'dma_free_coherent' drivers/usb/host/xhci-mem.c In function 'xhci_alloc_stream_ctx': drivers/usb/host/xhci-mem.c +463 : error: implicit declaration of function 'dma_alloc_coherent' Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-06-18xhci: check for failed dma pool allocationMathias Nyman
Fail and free the container context in case dma_pool_alloc() can't allocate the raw context data part of it This patch should be backported to kernels as old as 2.6.31, that contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci: Support for 64-byte contexts". Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-14xhci: remove BUG() in xhci_get_endpoint_type()Mathias Nyman
If the endpoint type is unknown, set it to 0 and fail gracefully instead of causing a kernel panic. Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-06-14xhci: Remove BUG in xhci_setup_addressable_virt_devMathias Nyman
We may have more speed types in the future, so fail gracefully, rather than causing the kernel to panic. BUG() was called if the device speed was unknown when setting max packet size. Set the max packet size at the same time as the slot speed and get rid of one switch statement with BUG() option completely. [Note: Sarah merged a patch that she wrote that touched the xhci_setup_addressable_virt_dev function with this patch from Mathias for clarity.] Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-06-14xhci: Remove BUG_ON in xhci_get_input_control_ctx.Sarah Sharp
Fail gracefully, instead of causing the kernel to panic, if the input control context doesn't have the right type (XHCI_CTX_TYPE_INPUT). Push finding the pointer to the input control context up into functions that can fail. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com>
2013-06-14xhci: Remove BUG_ON() in xhci_alloc_container_ctx.Sarah Sharp
It's horrible coding style to panic the kernel when someone passes you an argument value you didn't expect. In the future, we may want to add additional context types, so it's better to gracefully handle additional context types instead of panicking. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com>
2013-06-08Merge 3.10-rc5 into usb-nextGreg Kroah-Hartman
We need the changes in this branch. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-05usb: xhci: check usb2 port capabilities before adding hw link PM supportMathias Nyman
Hardware link powermanagement in usb2 is a per-port capability. Previously support for hw lpm was enabled for all ports if any usb2 port supported it. Now instead cache the capability values and check them for each port individually Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-05-24xhci: fix list access before initVladimir Murzin
If for whatever reason we fall into fail path in xhci_mem_init() before bw table gets initialized we may access the uninitialized lists in xhci_mem_cleanup(). Check for bw table before traversing lists in cleanup routine. This patch should be backported to kernels as old as 3.2, that contain the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store information about roothubs and TTs." Reported-by: Sergey Dyasly <dserrg@gmail.com> Tested-by: Sergey Dyasly <dserrg@gmail.com> Signed-off-by: Vladimir Murzin <murzin.v@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-05-24xhci-mem: init list heads at the beginning of initSergio Aguirre
It is possible that we fail on xhci_mem_init, just before doing the INIT_LIST_HEAD, and calling xhci_mem_cleanup. Problem is that, the list_for_each_entry_safe macro, assumes list heads are initialized (not NULL), and dereferences their 'next' pointer, causing a kernel panic if this is not yet initialized. Let's protect from that by moving inits to the beginning. This patch should be backported to kernels as old as 3.2, that contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test USB2 software LPM". Signed-off-by: Sergio Aguirre <sergio.a.aguirre.rodriguez@intel.com> Acked-by: David Cohen <david.a.cohen@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2013-05-15USB: xHCI: override bogus bulk wMaxPacketSize valuesAlan Stern
This patch shortens the logic in xhci_endpoint_init() by moving common calculations involving max_packet and max_burst outside the switch statement, rather than repeating the same code in multiple case-specific statements. It also replaces two usages of max_packet which were clearly intended to be max_burst all along. More importantly, it compensates for a common bug in high-speed bulk endpoint descriptors. In many devices there is a bulk endpoint having a wMaxPacketSize value smaller than 512, which is forbidden by the USB spec. Some xHCI controllers can't handle this and refuse to accept the endpoint. This patch changes the max_packet value to 512, which allows the controller to use the endpoint properly. In practice the bogus maxpacket size doesn't matter, because none of the transfers sent via these endpoints are longer than the maxpacket value anyway. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: "Aurélien Leblond" <blablack@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-04-03xhci: Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.hDavid Howells
Rename SEGMENT_SIZE and SEGMENT_SHIFT as the former is used in a.out.h. Signed-off-by: David Howells <dhowells@redhat.com> cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: linux-usb@vger.kernel.org Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-03-25usb: add find_raw_port_number callback to struct hc_driver()Lan Tianyu
xhci driver divides the root hub into two logical hubs which work respectively for usb 2.0 and usb 3.0 devices. They are independent devices in the usb core. But in the ACPI table, it's one device node and all usb2.0 and usb3.0 ports are under it. Binding usb port with its acpi node needs the raw port number which is reflected in the xhci extended capabilities table. This patch is to add find_raw_port_number callback to struct hc_driver(), fill it with xhci_find_raw_port_number() which will return raw port number and add a wrap usb_hcd_find_raw_port_number(). Otherwise, refactor xhci_find_real_port_number(). Using xhci_find_raw_port_number() to get real index in the HW port status registers instead of scanning through the xHCI roothub port array. This can help to speed up. All addresses in xhci->usb2_ports and xhci->usb3_ports array are kown good ports and don't include following bad ports in the extended capabilities talbe. (1) root port that doesn't have an entry (2) root port with unknown speed (3) root port that is listed twice and with different speeds. So xhci_find_raw_port_number() will only return port num of good ones and never touch bad ports above. Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-01-03xhci: Handle HS bulk/ctrl endpoints that don't NAK.Sarah Sharp
A high speed control or bulk endpoint may have bInterval set to zero, which means it does not NAK. If bInterval is non-zero, it means the endpoint NAKs at a rate of 2^(bInterval - 1). The xHCI code to compute the NAK interval does not handle the special case of zero properly. The current code unconditionally subtracts one from bInterval and uses it as an exponent. This causes a very large bInterval to be used, and warning messages like these will be printed: usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes This may cause the xHCI host hardware to reject the Configure Endpoint command, which means the HS device will be unusable under xHCI ports. This patch should be backported to kernels as old as 2.6.31, that contain commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in xhci_get_endpoint_interval()". Reported-by: Vincent Pelletier <plr.vincent@gmail.com> Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-11-12xhci: fix null-pointer dereference when destroying half-built segment ringsJulius Werner
xhci_alloc_segments_for_ring() builds a list of xhci_segments and links the tail to head at the end (forming a ring). When it bails out for OOM reasons half-way through, it tries to destroy its half-built list with xhci_free_segments_for_ring(), even though it is not a ring yet. This causes a null-pointer dereference upon hitting the last element. Furthermore, one of its callers (xhci_ring_alloc()) mistakenly believes the output parameters to be valid upon this kind of OOM failure, and calls xhci_ring_free() on them. Since the (incomplete) list/ring should already be destroyed in that case, this would lead to a use after free. This patch fixes those issues by having xhci_alloc_segments_for_ring() destroy its half-built, non-circular list manually and destroying the invalid struct xhci_ring in xhci_ring_alloc() with a plain kfree(). This patch should be backported to kernels as old as 2.6.31, that contains the commit 0ebbab37422315a5d0cb29792271085bafdf38c0 "USB: xhci: Ring allocation and initialization." A separate patch will need to be developed for kernels older than 3.4, since the ring allocation code was refactored in that kernel. Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-09-13xHCI: add aborting command ring functionElric Fu
Software have to abort command ring and cancel command when a command is failed or hang. Otherwise, the command ring will hang up and can't handle the others. An example of a command that may hang is the Address Device Command, because waiting for a SET_ADDRESS request to be acknowledged by a USB device is outside of the xHC's ability to control. To cancel a command, software will initialize a command descriptor for the cancel command, and add it into a cancel_cmd_list of xhci. Sarah: Fixed missing newline on "Have the command ring been stopped?" debugging statement. This patch should be backported to kernels as old as 3.0, that contain the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to check for virt_dev=0 bug." That commit papers over a NULL pointer dereference, and this patch fixes the underlying issue that caused the NULL pointer dereference. Signed-off-by: Elric Fu <elricfu1@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com> Cc: stable@vger.kernel.org
2012-06-13xhci: Don't free endpoints in xhci_mem_cleanup()Takashi Iwai
This patch fixes a few issues introduced in the recent fix [f8a9e72d: USB: fix resource leak in xhci power loss path] - The endpoints listed in bw table are just links and each entry is an array member of dev->eps[]. But the commit above adds a kfree() call to these instances, and thus it results in memory corruption. - It clears only the first entry of rh_bw[], but there can be multiple ports. - It'd be safer to clear the list_head of ep as well, not only removing from the list, as it's checked in xhci_discover_or_reset_device(). This patch should be backported to kernels as old as 3.2, that contain the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store information about roothubs and TTs." Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reviewed-by: Oliver Neukum <oneukum@suse.de> Cc: <stable@vger.kernel.org>
2012-06-13xhci: Fix invalid loop check in xhci_free_tt_info()Takashi Iwai
xhci_free_tt_info() may access the invalid memory when it removes the last entry but the list is not empty. Then tt_next reaches to the list head but it still tries to check the tt_info of that entry. This patch fixes the bug and cleans up the messy code by rewriting with a simple list_for_each_entry_safe(). This patch should be backported to kernels as old as 3.2, that contain the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store information about roothubs and TTs." Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Reviewed-by: Oliver Neukum <oneukum@suse.de> Cc: <stable@vger.kernel.org>
2012-05-18xhci: Reserve one command for USB3 LPM disable.Sarah Sharp
We want to do everything we can to ensure that USB 3.0 Link Power Management (LPM) can be disabled when it is enabled. If LPM can't be disabled, we can't suspend USB 3.0 devices, or reset them. To make sure we can submit the command to disable LPM, allocate a command in the xhci_hcd structure, and reserve one TRB on the command ring. We only need one command per xHCI driver instance, because LPM is only disabled or enabled while the USB core is holding the bandwidth_mutex that is shared between the xHCI USB 2.0 and USB 3.0 roothubs. The bandwidth_mutex will be held until the command completes, or times out. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-18xhci: Reset reserved command ring TRBs on cleanup.Sarah Sharp
When the xHCI driver needs to clean up memory (perhaps due to a failed register restore on resume from S3 or resume from S4), it needs to reset the number of reserved TRBs on the command ring to zero. Otherwise, several resume cycles (about 30) with a UAS device attached will continually increment the number of reserved TRBs, until all command submissions fail because there isn't enough room on the command ring. This patch should be backported to kernels as old as 2.6.32, that contain the commit 913a8a344ffcaf0b4a586d6662a2c66a7106557d "USB: xhci: Change how xHCI commands are handled." Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-05-18USB: fix resource leak in xhci power loss pathOliver Neukum
Some more data structures must be freed and counters reset if an XHCI controller has lost power. The failure to do so renders some chips inoperative after a certain number of S4 cycles. This patch should be backported to kernels as old as 3.2, that contain the commits c29eea621900f18287d50519f72cb9113746d75a "xhci: Implement HS/FS/LS bandwidth checking." and commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Implement HS/FS/LS bandwidth checking." Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
2012-04-11xhci: Don't write zeroed pointers to xHC registers.Sarah Sharp
When xhci_mem_cleanup() is called, we can't be sure if the xHC is actually halted. We can ask the xHC to halt by writing to the RUN bit in the command register, but that might timeout due to a HW hang. If the host controller is still running, we should not write zeroed values to the event ring dequeue pointers or base tables, the DCBAA pointers, or the command ring pointers. Eric Fu reports his VIA VL800 host accesses the event ring pointers after a failed register restore on resume from suspend. The hypothesis is that the host never actually halted before the register write to change the event ring pointer to zero. Remove all writes of zeroed values to pointer registers in xhci_mem_cleanup(). Instead, make all callers of the function reset the host controller first, which will reset those registers to zero. xhci_mem_init() is the only caller that doesn't first halt and reset the host controller before calling xhci_mem_cleanup(). This should be backported to kernels as old as 2.6.32. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Elric Fu <elricfu1@gmail.com> Cc: stable@vger.kernel.org
2012-03-13xHCI: Allocate 2 segments for transfer ringAndiry Xu
Allocate 2 segments for transfer ring by default, so we can expand the ring when the enqueue pointer and dequeue pointer are in different segments. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13xHCI: dynamic ring expansionAndiry Xu
If room_on_ring() check fails, try to expand the ring and check again. When expand a ring, use a cached ring or allocate new segments, link the original ring and the new ring or segments, update the original ring's segment numbers and the last segment pointer. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13xHCI: set cycle state when allocate ringsAndiry Xu
In the past all the rings were allocated with cycle state equal to 1. Now the driver may expand an existing ring, and the new segments shall be allocated with the same cycle state as the old one. This affects ring allocation and cached ring re-initialization. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13xHCI: factor out segments allocation and free functionAndiry Xu
Factor out the segments allocation and free part from ring allocation and free routines since driver may call them directly when try to expand a ring. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13xHCI: count free TRBs on transfer ringAndiry Xu
In the past, the room_on_ring() check was implemented by walking all over the ring, which is wasteful and complicated. Count the number of free TRBs instead. The free TRBs number should be updated when enqueue/dequeue pointer is updated, or upon the completion of a set dequeue pointer command. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13xHCI: store ring's last segment and segment numbersAndiry Xu
Store the ring's last segment pointer and number of segments for ring expansion usage. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-12xHCI: store ring's typeAndiry Xu
When allocate a ring, store its type - four transfer types for endpoint, TYPE_STREAM for stream transfer, and TYPE_COMMAND/TYPE_EVENT for xHCI host. This helps to get rid of three bool function parameters: link_trbs, isoc and consumer. Signed-off-by: Andiry Xu <andiry.xu@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-02-23Merge branch 'usb-3.3-rc4' into usb-nextGreg Kroah-Hartman
This is to pull in the xhci changes and the other fixes and device id updates that were done in Linus's tree. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-02-21xhci: Fix encoding for HS bulk/control NAK rate.Sarah Sharp
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
2012-02-14USB/xhci: Enable remote wakeup for USB3 devices.Sarah Sharp
When the USB 3.0 hub support went in, I disabled selective suspend for all external USB 3.0 hubs because they used a different mechanism to enable remote wakeup. In fact, other USB 3.0 devices that could signal remote wakeup would have been prevented from going into suspend because they would have stalled the SetFeature Device Remote Wakeup request. This patch adds support for the USB 3.0 way of enabling remote wake up (with a SetFeature Function Suspend request), and enables selective suspend for all hubs during hub_probe. It assumes that all USB 3.0 have only one "function" as defined by the interface association descriptor, which is true of all the USB 3.0 devices I've seen so far. FIXME if that turns out to change later. After a device signals a remote wakeup, it is supposed to send a Device Notification packet to the host controller, signaling which function sent the remote wakeup. The host can then put any other functions back into function suspend. Since we don't have support for function suspend (and no devices currently support it), we'll just assume the hub function will resume the device properly when it received the port status change notification, and simply ignore any device notification events from the xHCI host controller. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-12-22xhci: Remove debugging about ring structure allocation.Sarah Sharp
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>
2011-11-04xhci: Set slot and ep0 flags for address command.Sarah Sharp
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
2011-09-26usb/xhci: replace pci_*_consistent() with dma_*_coherent()Sebastian Andrzej Siewior
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>
2011-09-26xHCI: AMD isoc link TRB chain bit quirkAndiry Xu
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>
2011-09-26xHCI: test USB2 software LPMAndiry Xu
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>
2011-09-26xHCI: Check host USB2 LPM capabilityAndiry Xu
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>
2011-09-20xhci-mem.c: xhci_segment_free: No need for checking seg argumentKautuk Consul
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>
2011-09-20xhci-mem.c: Check for ring->first_seg != NULLKautuk Consul
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>
2011-09-20xhci: Fix mult base in endpoint bandwidth info.Sarah Sharp
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>
2011-09-09xHCI: refine td allocationAndiry Xu
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>
2011-09-09xhci: Track interval bandwidth tables per port/TT.Sarah Sharp
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>
2011-09-09xhci: Store endpoint bandwidth information.Sarah Sharp
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>
2011-09-09xhci: Store information about roothubs and TTs.Sarah Sharp
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>