- 11 12月, 2013 1 次提交
-
-
由 Dan Williams 提交于
Change the default enumeration scheme for xhci attached non-SuperSpeed devices from: Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(8) GetDescriptor(18) ...to: Reset [xhci address-device BSR = 1] GetDescriptor(64) Reset SetAddress [xhci address-device BSR = 0] GetDescriptor(18) ...as some devices misbehave when encountering a SetAddress command prior to GetDescriptor. There are known legacy devices that require this scheme, but testing has found at least one USB3 device that fails enumeration when presented with this ordering. For now, follow the ehci case and enable 'new scheme' by default for non-SuperSpeed devices. To support this enumeration scheme on xhci the AddressDevice operation needs to be performed twice. The first instance of the command enables the HC's device and slot context info for the device, but omits sending the device a SetAddress command (BSR == block set address request). Then, after GetDescriptor completes, follow up with the full AddressDevice+SetAddress operation. As mentioned before, this ordering of events with USB3 devices causes an extra state transition to be exposed to xhci. Previously USB3 devices would transition directly from 'enabled' to 'addressed' and never need to underrun responses to 'get descriptor'. We do see the 64-byte descriptor fetch the correct data, but the following 18-byte descriptor read after the reset gets: bLength = 0 bDescriptorType = 0 bcdUSB = 0 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 instead of: bLength = 12 bDescriptorType = 1 bcdUSB = 300 bDeviceClass = 0 bDeviceSubClass = 0 bDeviceProtocol = 0 bMaxPacketSize0 = 9 which results in the discovery process looping until falling back to 'old scheme' enumeration. Acked-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: NDavid Moore <david.moore@gmail.com> Suggested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 03 12月, 2013 8 次提交
-
-
由 Xenia Ragiadakou 提交于
Function xhci_write_64() is used to write 64bit xHC registers residing in MMIO. On 32bit systems, xHC registers need to be written with 32bit accesses by writing first the lower 32bits and then the higher 32bits. The header file asm-generic/io-64-nonatomic-lo-hi.h ensures that on 32bit systems writeq() will will write 64bit registers in 32bit chunks with low-high order. Replace all calls to xhci_write_64() with calls to writeq(). This is done to reduce code duplication since 64bit low-high write logic is already implemented and to take advantage of inherent "atomic" 64bit write operations on 64bit systems. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
Function xhci_read_64() is used to read 64bit xHC registers residing in MMIO. On 32bit systems, xHC registers need to be read with 32bit accesses by reading first the lower 32bits and then the higher 32bits. Replace all calls to xhci_read_64() with calls to readq() and include asm-generic/io-64-nonatomic-lo-hi.h header file, so that if the system is not 64bit, readq() will read registers in 32bit chunks with low-high order. This is done to reduce code duplication since 64bit low-high read logic is already implemented and to take advantage of inherent "atomic" 64bit read operations on 64bit systems. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
Function xhci_writel() is used to write a 32bit value in xHC registers residing in MMIO address space. It takes as first argument a pointer to the xhci_hcd although it does not use it. xhci_writel() internally simply calls writel(). This creates an illusion that xhci_writel() is an xhci specific function that has to be called in a context where a pointer to xhci_hcd is available. Remove xhci_writel() wrapper function and replace its calls with calls to writel() to make the code more straight-forward. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
Function xhci_readl() is used to read 32bit xHC registers residing in MMIO address space. It takes as first argument a pointer to the xhci_hcd although it does not use it. xhci_readl() internally simply calls readl(). This creates an illusion that xhci_readl() is an xhci specific function that has to be called in a context where a pointer to xhci_hcd is available. Remove the unnecessary xhci_readl() wrapper function and replace its calls to with calls to readl() to make the code more straightforward. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
The fields 'add_flags' and 'drop_flags' in struct xhci_input_control_ctx have type __le32 and need to be converted to CPU byteorder before being used to derive the number of dropped endpoints. This bug was found using sparse. This patch is not suitable for stable, since the bug would only be triggered on big endian systems, and the code only runs for Intel xHCI host controllers, which are always integrated into little endian systems. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
The fields 'add_flags' and 'drop_flags' in struct xhci_input_control_ctx have type __le32 and need to be converted to CPU byteorder before being used to derive the number of added endpoints. This bug was found using sparse. This patch is not suitable for stable, since the bug would only be triggered on big endian systems, and the code only runs for Intel xHCI host controllers, which are always integrated into little endian systems. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch replaces USB_MAXINTERFACES with config->desc.bNumInterface in the termination condition for the loop that updates the LPM timeout of the endpoints on the cofiguration's interfaces, in xhci_calculate_lpm_timeout(), to avoid unnecessary loop cycles since most configurations come with 1-2 interfaces while USB_MAXINTERFACES is 32. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
The field 'dev_info' in struct xhci_slot_ctx has type __le32 and it needs to be converted to CPU byteorder for the correct retrieval of its subfield 'Context Entries'. This field is used by the trace event 'xhci_address_ctx' to trace only the contexts of valid endpoints. This bug was found using sparse. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 17 10月, 2013 5 次提交
-
-
由 Dan Williams 提交于
Only used for debug output, so we don't need to save it. Signed-off-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 xiao jin 提交于
The usage of USB_CTRL_SET_TIMEOUT in xhci is incorrect. The definition of USB_CTRL_SET_TIMEOUT is 5000ms. The input timeout to wait_for_completion_interruptible_timeout is jiffies. That makes the timeout be longer than what we want, such as 50s in some platform. The patch is to use XHCI_CMD_DEFAULT_TIMEOUT instead of USB_CTRL_SET_TIMEOUT as command completion event timeout. Signed-off-by: Nxiao jin <jin.xiao@intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
The USB core currently handles enabling and disabling optional USB power management features during device transitions (device suspend/resume, driver bind/unbind, device reset, and device disconnect). Those optional power features include Latency Tolerance Messaging (LTM), USB 3.0 Link PM, and USB 2.0 Link PM. The USB core currently enables LPM on device enumeration and disables USB 2.0 Link PM when the device is reset. However, the xHCI driver disables LPM when the device is disconnected and the device context is freed. Push the call up into the USB core, in order to be consistent with the core handling all power management enabling and disabling. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
How it's supposed to work: -------------------------- USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices support. USB 3.0 devices certified by the USB-IF are required to support it if they are plugged into a USB 2.0 only port, or a USB 2.0 cable is used. USB 2.0 Link PM requires both a USB device and a host controller that supports USB 2.0 hardware-enabled LPM. USB 2.0 Link PM is designed to be enabled once by software, and the host hardware handles transitions to the L1 state automatically. The premise of USB 2.0 Link PM is to be able to put the device into a lower power link state when the bus is idle or the device NAKs USB IN transfers for a specified amount of time. ...but hardware is broken: -------------------------- It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by setting the LPM bit in their USB 2.0 BOS descriptor), but they don't actually implement it correctly. This manifests as the USB device refusing to respond to transfers when it is plugged into a USB 2.0 only port under the Haswell-ULT/Lynx Point LP xHCI host. These devices pass the xHCI driver's simple test to enable USB 2.0 Link PM, wait for the port to enter L1, and then bring it back into L0. They only start to break when L1 entry is interleaved with transfers. Some devices then fail to respond to the next control transfer (usually a Set Configuration). This results in devices never enumerating. Other mass storage devices (such as a later model Western Digital My Passport USB 3.0 hard drive) respond fine to going into L1 between control transfers. They ACK the entry, come out of L1 when the host needs to send a control transfer, and respond properly to those control transfers. However, when the first READ10 SCSI command is sent, the device NAKs the data phase while it's reading from the spinning disk. Eventually, the host requests to put the link into L1, and the device ACKs that request. Then it never responds to the data phase of the READ10 command. This results in not being able to read from the drive. Some mass storage devices (like the Corsair Survivor USB 3.0 flash drive) are well behaved. They ACK the entry into L1 during control transfers, and when SCSI commands start coming in, they NAK the requests to go into L1, because they need to be at full power. Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I suspect that means the device isn't certified. What do we do about it? ----------------------- There's really no good way for the kernel to test these devices. Therefore, the kernel needs to disable USB 2.0 Link PM by default, and distros will have to enable it by writing 1 to the sysfs file /sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link PM test, since it's not sufficient to detect these buggy devices, and don't automatically enable LPM after the device is addressed. This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdc "usb: xhci: add USB2 Link power management BESL support". Without this fix, some USB 3.0 devices will not enumerate or work properly under USB 2.0 ports on Haswell-ULT systems. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
To enable USB 2.0 Link Power Management (LPM), the xHCI host controller needs the device slot ID to generate the device address used in L1 entry tokens. That information is set in the L1 device slot ID field of the USB 2.0 LPM registers. Currently, the L1 device slot ID is overwritten when the xHCI driver initiates the software test of USB 2.0 Link PM in xhci_usb2_software_lpm_test. It is never cleared when USB 2.0 Link PM is disabled for the device. That should be harmless, because the Hardware LPM Enable (HLE) bit is cleared when USB 2.0 Link PM is disabled, so the host should not pay attention to the slot ID. This patch should have no effect on host behavior, but since xhci_usb2_software_lpm_test is going away in an upcoming bug fix patch, we need to move that code to the function that enables and disables USB 2.0 Link PM. This patch should be backported to kernels as old as 3.11, that contain the commit a558ccdc "usb: xhci: add USB2 Link power management BESL support". The upcoming bug fix patch is also marked for that stable kernel. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 10 10月, 2013 2 次提交
-
-
由 Takashi Iwai 提交于
Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show mysterious wakeups after shutdown occasionally. After discussing with BIOS engineers, they explained that the new BIOS expects that the wakeup sources are cleared and set to D3 for all wakeup devices when the system is going to sleep or power off, but the current xhci driver doesn't do this properly (partly intentionally). This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci shutdown ops as done in xhci_stop(), and setting the device to PCI D3 at shutdown and remove ops. The PCI D3 call is based on the initial fix patch by Oliver Neukum. [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names in them. Sarah also fixed a collision with a quirk submitted around the same time, by changing the xhci->quirks bit from 17 to 18.] This patch should be backported to kernels as old as 3.0, that contain the commit 1c12443a "xhci: Add Lynx Point to list of Intel switchable hosts." Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
由 Oliver Neukum 提交于
It has been reported that this chipset really cannot sleep without this extraordinary delay. This patch should be backported, in order to ensure this host functions under stable kernels. The last quirk for Fresco Logic hosts (commit bba18e33 "xhci: Extend Fresco Logic MSI quirk.") was backported to stable kernels as old as 2.6.36. Signed-off-by: NOliver Neukum <oneukum@suse.de> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 24 9月, 2013 1 次提交
-
-
由 Mathias Nyman 提交于
If a command on the command ring needs to be cancelled before it is handled it can be turned to a no-op operation when the ring is stopped. We want to store the command ring enqueue pointer in the command structure when the command in enqueued for the cancellation case. Some commands used to store the command ring dequeue pointers instead of enqueue (these often worked because enqueue happends to equal dequeue quite often) Other commands correctly used the enqueue pointer but did not check if it pointed to a valid trb or a link trb, this caused for example stop endpoint command to timeout in xhci_stop_device() in about 2% of suspend/resume cases. This should also solve some weird behavior happening in command cancellation cases. This patch is based on a patch submitted by Sarah Sharp to linux-usb, but then forgotten: http://marc.info/?l=linux-usb&m=136269803207465&w=2 This patch should be backported to kernels as old as 3.7, that contain the commit b92cc66c "xHCI: add aborting command ring function" Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 29 8月, 2013 1 次提交
-
-
由 Sarah Sharp 提交于
The 0day build server caught a new build warning that is triggered when CONFIG_USB_DEFAULT_PERSIST is turned on: tree: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git for-usb-next head: 0730d52a commit: c8476fb8 [1/3] usb: xhci: Disable runtime PM suspend for quirky controllers config: i386-randconfig-r6-0826 (attached as .config) All warnings: drivers/usb/host/xhci.c: In function 'xhci_free_dev': >> drivers/usb/host/xhci.c:3560:17: warning: unused variable 'dev' [-Wunused-variable] struct device *dev = hcd->self.controller; ^ drivers/usb/host/xhci.c: In function 'xhci_alloc_dev': >> drivers/usb/host/xhci.c:3648:17: warning: unused variable 'dev' [-Wunused-variable] struct device *dev = hcd->self.controller; ^ vim +/dev +3560 drivers/usb/host/xhci.c 3554 * disabled. Free any HC data structures associated with that device. 3555 */ 3556 void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev) 3557 { 3558 struct xhci_hcd *xhci = hcd_to_xhci(hcd); 3559 struct xhci_virt_device *virt_dev; > 3560 struct device *dev = hcd->self.controller; 3561 unsigned long flags; 3562 u32 state; 3563 int i, ret; 3564 3565 #ifndef CONFIG_USB_DEFAULT_PERSIST 3566 /* 3567 * We called pm_runtime_get_noresume when the device was attached. 3568 * Decrement the counter here to allow controller to runtime suspend 3569 * if no devices remain. 3570 */ 3571 if (xhci->quirks & XHCI_RESET_ON_RESUME) 3572 pm_runtime_put_noidle(dev); 3573 #endif 3574 ... 3641 /* 3642 * Returns 0 if the xHC ran out of device slots, the Enable Slot command 3643 * timed out, or allocating memory failed. Returns 1 on success. 3644 */ 3645 int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev) 3646 { 3647 struct xhci_hcd *xhci = hcd_to_xhci(hcd); > 3648 struct device *dev = hcd->self.controller; 3649 unsigned long flags; 3650 int timeleft; 3651 int ret; Fix this. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Shawn Nematbakhsh <shawnn@chromium.org>
-
- 27 8月, 2013 1 次提交
-
-
由 Shawn Nematbakhsh 提交于
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend, a reset will be performed upon runtime resume. Any previously suspended devices attached to the controller will be re-enumerated at this time. This will cause problems, for example, if an open system call on the device triggered the resume (the open call will fail). Note that this change is only relevant when persist_enabled is not set for USB devices. This patch should be backported to kernels as old as 3.0, that contain the commit c877b3b2 "xhci: Add reset on resume quirk for asrock p67 host". Signed-off-by: NShawn Nematbakhsh <shawnn@chromium.org> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 16 8月, 2013 1 次提交
-
-
由 Sarah Sharp 提交于
The xHCI platform driver calls into usb_add_hcd to register the irq for its platform device. It does not want the xHCI generic driver to register an interrupt for it at all. The original code did that by setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not enable MSI or MSI-X for a PCI host. Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled, the xHCI generic driver will attempt to register a legacy PCI interrupt for the xHCI platform device in xhci_try_enable_msi(). This will result in a bogus irq being registered, since the underlying device is a platform_device, not a pci_device, and thus the pci_device->irq pointer will be bogus. Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can distinguish between a PCI device that can't handle MSI or MSI-X, and a platform device that should not have its interrupts touched at all. This quirk may be useful in the future, in case other corner cases like this arise. This patch should be backported to kernels as old as 3.9, that contain the commit 00eed9c8 "USB: xhci: correctly enable interrupts". Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: NYu Y Wang <yu.y.wang@intel.com> Tested-by: NYu Y Wang <yu.y.wang@intel.com> Reviewed-by: NFelipe Balbi <balbi@ti.com> Cc: stable@vger.kernel.org
-
- 14 8月, 2013 11 次提交
-
-
由 Xenia Ragiadakou 提交于
The function dma_set_mask() tests internally whether the dma_mask pointer for the device is initialized and fails if the dma_mask pointer is NULL. On pci platforms, the device dma_mask pointer is initialized, when pci devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff. However, for non-pci platforms, the dma_mask pointer may not be initialized and in that case dma_set_mask() will fail. This patch initializes the dma_mask and the coherent_dma_mask to 32bits in xhci_plat_probe(), before the call to usb_create_hcd() that sets the "uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates coherent dma pools for the usb hcd. Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask. Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc() to allocate consistent DMA memory blocks, the coherent DMA address mask has to be set explicitly. This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when the xHC is capable for 64-bit DMA addressing. If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that the given bitmask is also supported for consistent DMA mappings. Other changes introduced in this patch are: - The return value of dma_set_mask() is checked to ensure that the required dma bitmask conforms with the host system's addressing capabilities. - The dma_mask setup code for the non-primary hcd was removed since both primary and non-primary hcd refer to the same generic device whose dma_mask and coherent_dma_mask are already set during the setup of the primary hcd. - The code for reading the HCCPARAMS register to find out the addressing capabilities of xHC was removed since its value is already cached in xhci->hccparams. - hcd->self.controller was replaced with the dev variable since it is already available. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia 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: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch defines a new trace event, which is called xhci_dbg_cancel_urb and belongs to the event class xhci_log_msg, and adds tracepoints that trace the debug messages related to the removal of a cancelled URB from the endpoint's transfer ring. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch defines a new event class, called xhci_log_ctx, that records in the ring buffer the context data, the context type (input or output), the context dma and virtual addresses, the context endpoint entries, the slot ID and whether the xHC uses 64 byte context data structures. This information can be used, later, to parse and display the context data fields with the appropriate plugin using the trace-cmd tool. Also, this patch defines a trace event, called xhci_address_ctx, to trace the contexts related to the Address Device command and adds the associated tracepoints in xhci_address_device(). Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch defines a new trace event, which is called xhci_dbg_reset_ep and belongs in the event class xhci_log_msg, and adds tracepoints that trace the debug messages associated with resetting an endpoint after the reception of a STALL packet. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch defines a new trace event, which is called xhci_dbg_quirks and belongs in the event class xhci_log_msg, and adds tracepoints that trace the debug messages associated with xHCs' quirks. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia 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: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch declares an event class for trace events that trace messages with variadic arguments, called xhci_log_msg, and defines a trace event for tracing the debug messages in xhci_address_device() function, called xhci_dbg_address. In order to implement this type of trace events, a wrapper function, called xhci_dbg_trace(), was created that records the format string and variadic arguments into a va_format structure which is passed as argument to the tracepoints of the class xhci_log_msg. All the xhci_dbg() calls in xhci_address_device() are replaced with calls to xhci_dbg_trace(). The functionality of xhci_dbg() log messages was not removed though, but it is placed inside xhci_dbg_trace(). This trace event aims to give the ability to the user or the developper to isolate and trace the debug messages generated when an Address Device Command is issued to xHC. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia 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: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch replaces the calls to printk(KERN_DEBUG ...) with either calls to xhci_dbg() or calls to pr_debug(), depending on whether the xhci_hcd structure is available at callsite, so that the correspoding debugging messages are not enabled by default when CONFIG_DYNAMIC_DEBUG option is set but rather can be enabled dynamically taking advantage of the dynamic debugging feature. Also, it adds a newline at the end of debugging messages in case there is not, so that messages don't appear broken when printed. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Xenia Ragiadakou 提交于
This patch replaces the calls to xhci_info() with calls to xhci_dbg() and removes the unused xhci_info() definition from xhci-hcd. By replacing the xhci_info() with xhci_dbg(), the calls to dev_info() are replaced with calls to dev_dbg() so that their output can be dynamically controlled via the dynamic debugging mechanism. Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 13 8月, 2013 1 次提交
-
-
由 Ming Lei 提交于
This patch marks all xHCI controllers as no_sg_constraint since xHCI supports building packet from discontinuous buffers. Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NMing Lei <ming.lei@canonical.com> Reviewed-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 01 8月, 2013 1 次提交
-
-
由 James 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: NJames Hogan <james.hogan@imgtec.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 25 7月, 2013 3 次提交
-
-
由 George Cherian 提交于
Xhci controllers with hci_version > 0.96 gives spurious success events on short packet completion. During webcam capture the "ERROR Transfer event TRB DMA ptr not part of current TD" was observed. The same application works fine with synopsis controllers hci_version 0.96. The same issue is seen with Intel Pantherpoint xhci controller. So enabling this quirk in xhci_gen_setup if controller verion is greater than 0.96. For xhci-pci move the quirk to much generic place xhci_gen_setup. Note from Sarah: The xHCI 1.0 spec changed how hardware handles short packets. The HW will notify SW of the TRB where the short packet occurred, and it will also give a successful status for the last TRB in a TD (the one with the IOC flag set). On the second successful status, that warning will be triggered in the driver. Software is now supposed to not assume the TD is not completed until it gets that last successful status. That means we have a slight race condition, although it should have little practical impact. This patch papers over that issue. It's on my long-term to-do list to fix this race condition, but it is a much more involved patch that will probably be too big for stable. This patch is needed for stable to avoid serious log spam. This patch should be backported to kernels as old as 3.0, that contain the commit ad808333 "Intel xhci: Ignore spurious successful event." The patch will have to be modified for kernels older than 3.2, since that kernel added the xhci_gen_setup function for xhci platform devices. The correct conflict resolution for kernels older than 3.2 is to set XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts. Signed-off-by: NGeorge Cherian <george.cherian@ti.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
由 Olof Johansson 提交于
Resolves the following build warnings: drivers/usb/host/xhci.c:332:13: warning: 'xhci_msix_sync_irqs' defined but not used [-Wunused-function] drivers/usb/host/xhci.c:3901:12: warning: 'xhci_change_max_exit_latency' defined but not used [-Wunused-function] These functions are not always used, and since they're marked static they will produce build warnings: - xhci_msix_sync_irqs is only used with CONFIG_PCI. - xhci_change_max_exit_latency is a little more complicated with dependencies on CONFIG_PM and CONFIG_PM_RUNTIME. Instead of building a bigger maze of ifdefs in this code, I've just marked both with __maybe_unused. Signed-off-by: NOlof Johansson <olof@lixom.net> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
When the host controller fails to respond to an Enable Slot command, and the host fails to respond to the register write to abort the command ring, the xHCI driver will assume the host is dead, and call usb_hc_died(). The USB device's slot_id is still set to zero, and the pointer stored at xhci->devs[0] will always be NULL. The call to xhci_check_args in xhci_free_dev should have caught the NULL virt_dev pointer. However, xhci_free_dev is designed to free the xhci_virt_device structures, even if the host is dead, so that we don't leak kernel memory. xhci_free_dev checks the return value from the generic xhci_check_args function. If the return value is -ENODEV, it carries on trying to free the virtual device. The issue is that xhci_check_args looks at the host controller state before it looks at the xhci_virt_device pointer. It will return -ENIVAL because the host is dead, and xhci_free_dev will ignore the return value, and happily dereference the NULL xhci_virt_device pointer. The fix is to make sure that xhci_check_args checks the xhci_virt_device pointer before it checks the host state. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for further details. This patch doesn't solve the underlying issue, but will ensure we don't see any more NULL pointer dereferences because of the issue. This patch should be backported to kernels as old as 3.1, that contain the commit 7bd89b40 "xhci: Don't submit commands or URBs to halted hosts." Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: NVincent Thiele <vincentthiele@gmail.com> Cc: stable@vger.kernel.org
-
- 24 7月, 2013 1 次提交
-
-
由 Joe Perches 提交于
Logging messages end in newlines, not have them put in the middle of messages. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 26 6月, 2013 1 次提交
-
-
由 Emil Goode 提交于
This patch adds missing unlocks on error paths in the xhci_free_streams and xhci_configure_endpoint functions. Signed-off-by: NEmil Goode <emilgoode@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 6月, 2013 1 次提交
-
-
由 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: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com>
-
- 06 6月, 2013 1 次提交
-
-
由 Mathias Nyman 提交于
Adds abitilty to tune L1 timeout (inactivity timer for usb2 link sleep) and BESL (best effort service latency)via sysfs. This also adds a new usb2_lpm_parameters structure with those variables to struct usb_device. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-