- 18 5月, 2017 1 次提交
-
-
由 Mathias Nyman 提交于
In 4.11 TRB completion codes were renamed to match spec. Completion codes for command ring stopped and endpoint stopped were mixed, leading to failures while handling a stopped command ring. Use the correct completion code for command ring stopped events. Fixes: 0b7c105a ("usb: host: xhci: rename completion codes to match spec") Cc: <stable@vger.kernel.org> # 4.11 Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 4月, 2017 1 次提交
-
-
由 Mathias Nyman 提交于
commit a6ff6cbf ("usb: xhci: Add helper function xhci_set_power_on().") created a helper to control port power that needs to be called with xhci->lock held and interrupts disabled. It released the lock with spin_unlock_irqrestore using a new zero flag variable instead of the original flag from spin_lock_irqsave. This regression triggered a static checker warning about bogus flags, and a null pointer dereference on armada-385. Fix it by passing a pointer to the correct flags and using it instead Fixes: a6ff6cbf ("usb: xhci: Add helper function xhci_set_power_on().") Cc: Guoqing Zhang <guoqing.zhang@intel.com> Reported-by: NRalph Sennhauser <ralph.sennhauser@gmail.com> Tested-by: NRalph Sennhauser <ralph.sennhauser@gmail.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 08 4月, 2017 4 次提交
-
-
由 Lu Baolu 提交于
Omit extra messages for memory allocation failure. Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
Introduce a new xhci_hc_died() function that takes care of handling pending commands and URBs if a host controller becomes unresponsive. This addresses issues on hotpluggable xhci controllers that disappear from the bus suddenly, often while the bus (PCI) remove function is still being processed. xhci_hc_died() sets a XHCI_STATUS_DYING flag to prevent new URBs and commands or to be queued. The flag also ensures xhci_hc_died() will give back pending commands and URBs once. Host is considered dead if register read returns 0xffffffff, or host fails to abort the command ring, or fails stopping an endpoint after trying for 5 seconds. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Guoqing Zhang 提交于
For usb2 ports, the port test mode Test_J_State, Test_K_State, Test_Packet, Test_SE0_NAK and Test_Force_En can be enabled as described in usb2 spec. USB2 test mode is a required hardware feature for system integrators validating their hardware according to USB spec, regarding signal strength and stuff. It is purely a hardware test feature. Usually you need an oscilloscope and have to enable those test modes on the hardware. This will send some specific test patterns on D+/D-. There is no report available (in Linux itself) as it is purely externally visible. Regular USB usage is not possible at that time. Anyone (well access to e.g. /dev/bus/usb/001/001 provided) can use it by sending appropriate USB_PORT_FEAT_TEST requests to the hub. [Add better commit message by Alexander Stein -Mathias] Signed-off-by: NGuoqing Zhang <guoqing.zhang@intel.com> Cc: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Guoqing Zhang 提交于
Refactoring port power on/off related code into a helper function xhci_set_power_on() which can be reused when enabling test mode. [set port state to neutral before writing port power -Mathias] Signed-off-by: NGuoqing Zhang <guoqing.zhang@intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 1月, 2017 4 次提交
-
-
由 Felipe Balbi 提交于
Let's start tracing at least part of an xhci_virt_device lifetime. We might want to extend this tracepoint class later, but for now it already exposes quite a bit of valuable information. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Felipe Balbi 提交于
Cleanup only. This patch is a mechaninal rename to make sure our macros for TRB completion codes match what the specification uses to refer to such errors. The idea behind this is that it makes it far easier to grep the specification and match it with implementation. Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Felipe Balbi 提交于
Some devices from Texas Instruments [1] suffer from a silicon bug where Port Enabled/Disabled bit should not be used to silence an erroneous device. The bug is so that if port is disabled with PED bit, an IRQ for device removal (or attachment) will never fire. Just for the sake of completeness, the actual problem lies with SNPS USB IP and this affects all known versions up to 3.00a. A separate patch will be added to dwc3 to enabled this quirk flag if version is <= 3.00a. [1] - AM572x Silicon Errata http://www.ti.com/lit/er/sprz429j/sprz429j.pdf Section i896— USB xHCI Port Disable Feature Does Not Work Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NRoger Quadros <rogerq@ti.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alexander Stein 提交于
This allows someone to grep for the complete warning message as in; xhci-hcd xhci-hcd.0.auto: USB core suspending device not in U0/U1/U2. Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 20 10月, 2016 2 次提交
-
-
由 Mathias Nyman 提交于
USB2 host inititated resume, and system suspend bus resume need to use the same USB_RESUME_TIMEOUT as elsewhere. This resolves a device disconnect issue at system resume seen on Intel Braswell and Apollolake, but is in no way limited to those platforms. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> CC: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
If a device is unplugged and replugged during Sx system suspend some Intel xHC hosts will overwrite the CAS (Cold attach status) flag and no device connection is noticed in resume. A device in this state can be identified in resume if its link state is in polling or compliance mode, and the current connect status is 0. A device in this state needs to be warm reset. Intel 100/c230 series PCH specification update Doc #332692-006 Errata #8 Observed on Cherryview and Apollolake as they go into compliance mode if LFPS times out during polling, and re-plugged devices are not discovered at resume. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> CC: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 8月, 2016 1 次提交
-
-
由 Jim Lin 提交于
After a device is disconnected, xhci_stop_device() will be invoked in xhci_bus_suspend(). Also the "disconnect" IRQ will have ISR to invoke xhci_free_virt_device() in this sequence. xhci_irq -> xhci_handle_event -> handle_cmd_completion -> xhci_handle_cmd_disable_slot -> xhci_free_virt_device If xhci->devs[slot_id] has been assigned to NULL in xhci_free_virt_device(), then virt_dev->eps[i].ring in xhci_stop_device() may point to an invlid address to cause kernel panic. virt_dev = xhci->devs[slot_id]; : if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue) [] Unable to handle kernel paging request at virtual address 00001a68 [] pgd=ffffffc001430000 [] [00001a68] *pgd=000000013c807003, *pud=000000013c807003, *pmd=000000013c808003, *pte=0000000000000000 [] Internal error: Oops: 96000006 [#1] PREEMPT SMP [] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U [] Workqueue: pm pm_runtime_work [] task: ffffffc0bc0e0bc0 ti: ffffffc0bc0ec000 task.ti: ffffffc0bc0ec000 [] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4 This issue is found when running with realtek ethernet device (0bda:8153). Signed-off-by: NJim Lin <jilin@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 2月, 2016 1 次提交
-
-
由 Mathias Nyman 提交于
If a xhci controller does not provide a protocol speed ID (PSI) table, a default one should be used instead. Add the default values to the SuperSpeedPlus device capability. Overwrite the default ones if a PSI table exists. See xHCI 1.1 sectio 7.2.2.1.1 for more info Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 12月, 2015 1 次提交
-
-
由 Mathias Nyman 提交于
According to USB 2 specs ports need to signal resume for at least 20ms, in practice even longer, before moving to U0 state. Both host and devices can initiate resume. On device initiated resume, a port status interrupt with the port in resume state in issued. The interrupt handler tags a resume_done[port] timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer. Root hub timer requests for port status, finds the port in resume state, checks if resume_done[port] timestamp passed, and set port to U0 state. On host initiated resume, current code sets the port to resume state, sleep 20ms, and finally sets the port to U0 state. This should also be changed to work in a similar way as the device initiated resume, with timestamp tagging, but that is not yet tested and will be a separate fix later. There are a few issues with this approach 1. A host initiated resume will also generate a resume event. The event handler will find the port in resume state, believe it's a device initiated resume, and act accordingly. 2. A port status request might cut the resume signalling short if a get_port_status request is handled during the host resume signalling. The port will be found in resume state. The timestamp is not set leading to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0. get_port_status will proceed with moving the port to U0. 3. If an error, or anything else happens to the port during device initiated resume signalling it will leave all the device resume parameters hanging uncleared, preventing further suspend, returning -EBUSY, and cause the pm thread to busyloop trying to enter suspend. Fix this by using the existing resuming_ports bitfield to indicate that resume signalling timing is taken care of. Check if the resume_done[port] is set before using it for timestamp comparison, and also clear out any resume signalling related variables if port is not in U0 or Resume state This issue was discovered when a PM thread busylooped, trying to runtime suspend the xhci USB 2 roothub on a Dell XPS Cc: stable <stable@vger.kernel.org> Reported-by: NDaniel J Blueman <daniel@quora.org> Tested-by: NDaniel J Blueman <daniel@quora.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 12月, 2015 1 次提交
-
-
由 Mathias Nyman 提交于
use the variables defined for populating the port status and port chage bits retuend by GetPortStatus request intead of the hub class feature selectors. The defines for hub class feature selectors are used for other purposes, they work as port status and feature selectors are in the same order, and set the same bits, but it makes the code very hard to follow Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 11月, 2015 1 次提交
-
-
由 Mathias Nyman 提交于
Clear device initiated resume variables once device is fully up and running in U0 state. Resume needs to be signaled for 20ms for usb2 devices before they can be moved to U0 state. An interrupt is triggered if a device initiates resume. As we handle the event in interrupt context we can not sleep for 20ms, so we instead set a resume flag, a timestamp, and start the roothub polling. The roothub code will later move the port to U0 when it finds a port in resume state with the resume flag set, and timestamp passed by 20ms. A host initiated resume is however not done in interrupt context, and host initiated resume code will directly signal resume, wait 20ms and then move the port to U0. These two codepaths can race, if we are in the middle of a host initated resume, while sleeping for 20ms, we may handle a port event and find the port in resume state. The port event handling code will assume the resume was device initiated and set the resume flag and timestamp. Root hub code will however not catch the port in resume state again as the host initated resume code has already moved the port to U0. The resume flag and timestamp will remain set for this port preventing port from suspending again (LPM setting port to U3) Fix this for now by always clearing the device initated resume parameters once port is in U0 Cc: stable <stable@vger.kernel.org> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 10月, 2015 4 次提交
-
-
由 Mathias Nyman 提交于
USB 3.1 adds different types of Get Port Status request. The Get Extended Port Status request returns 4 additional bytes after the normal portstatus and portchange words containing link speed and lane information about a connected enhanced super speed device Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
Set the controller speed to HCD_USB31 to if host hardware supports USB 3.1 For PCI xhci controllers the USB 3.1 support is checked from SBRN bits in pci config space. Platform controllers will need to set xhci->sbrn == 0x31 to indicate USB 3.1 support before calling xhci_gen_setup(). Also make sure xhci driver works correctly with speed set to HCD_USB31 Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
USB 3.1 capable xhci controllers use a new default speed ID "5" in the PORTSC register to represent a 10Gbps connection speed of a SuperSpeedPlus device Make sure the xhci driver can handle the returned SuperSpeedPlus speed ID properly Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
All usb devices that support USB 3.1 Gen2 speeds need to provide a SuperSpeedPlus device capability descriptor as part of their BOS descriptor. If the xhci controller supports USB 3.1 enhanced SuperSpeed, meaning it can handle both Gen1 SuperSpeed 5Gbps and Gen2 SuperSpeedPlus 10Gbps devices, then we need to provide a SuperSpeedPlus capability descriptor for the USB 3.1 roothub as well. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 23 7月, 2015 3 次提交
-
-
由 Zhuang Jin Can 提交于
Port link change with port in resume state should not be reported to usbcore, as this is an internal state to be handled by xhci driver. Reporting PLC to usbcore may cause usbcore clearing PLC first and port change event irq won't be generated. Cc: <stable@vger.kernel.org> Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Zhuang Jin Can 提交于
When the link is just waken, it's in Resume state, and driver sets PLS to U0. This refers to Phase 1. Phase 2 refers to when the link has completed the transition from Resume state to U0. With the fix of xhci: report U3 when link is in resume state, it also exposes an issue that usb3 roothub and controller can suspend right after phase 1, and this causes a hard hang in controller. To fix the issue, we need to prevent usb3 bus suspend if any port is resuming in phase 1. [merge separate USB2 and USB3 port resume checking to one -Mathias] Cc: <stable@vger.kernel.org> Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Zhuang Jin Can 提交于
xhci_hub_report_usb3_link_state() returns pls as U0 when the link is in resume state, and this causes usb core to think the link is in U0 while actually it's in resume state. When usb core transfers control request on the link, it fails with TRB error as the link is not ready for transfer. To fix the issue, report U3 when the link is in resume state, thus usb core knows the link it's not ready for transfer. Cc: <stable@vger.kernel.org> Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 31 5月, 2015 1 次提交
-
-
由 Mathias Nyman 提交于
We used to write the root port state changes in turn for every port, sleeping 20ms after every port state change. Suspended usb2 ports need two state changes, taking minimun 40ms per port. Now instead poll the Port Link State Change (PLC) bit as the state change to U0 will set this bit. Suspended usb2 ports still need the extra 20ms delay, but we now change all the port states at once so we only need to sleep 20ms once all together Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 3月, 2015 1 次提交
-
-
由 Lu Baolu 提交于
Linux xHCI driver doesn't report and handle port cofig error change. If Port Configure Error for root hub port occurs, CEC bit in PORTSC would be set by xHC and remains 1. This happends when the root port fails to configure its link partner, e.g. the port fails to exchange port capabilities information using Port Capability LMPs. Then the Port Status Change Events will be blocked until all status change bits(CEC is one of the change bits) are cleared('0') (refer to xHCI spec 4.19.2). Otherwise, the port status change event for this root port will not be generated anymore, then root port would look like dead for user and can't be recovered until a Host Controller Reset(HCRST). This patch is to check CEC bit in PORTSC in xhci_get_port_status() and set a Config Error in the return status if CEC is set. This will cause a ClearPortFeature request, where CEC bit is cleared in xhci_clear_port_change_bit(). [The commit log is based on initial Marvell patch posted at http://marc.info/?l=linux-kernel&m=142323612321434&w=2] Reported-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Cc: stable <stable@vger.kernel.org> # v3.2+ Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 12月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
After commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so quite a few depend on CONFIG_PM (or even dropped in some cases). Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code and documentation. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 11月, 2014 1 次提交
-
-
由 Lu Baolu 提交于
commit ff8cbf25 ("xhci: clear root port wake on bits if controller isn't") can cause device detection error if runtime PM is enabled, and S3 wake is disabled. Revert it. https://bugzilla.kernel.org/show_bug.cgi?id=85701 This commit got into stable and should be reverted from there as well. Cc: stable <stable@vger.kernel.org> # v3.2+ Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Reported-by: NDmitry Nezhevenko <dion@inhex.net> [Mathias Nyman: reword commit message] Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 24 9月, 2014 2 次提交
-
-
由 Petr Mladek 提交于
USB hub has started to use a workqueue instead of kthread. Let's update the documentation and comments here and there. This patch mostly just replaces "khubd" with "hub_wq". There are only few exceptions where the whole sentence was updated. These more complicated changes can be found in the following files: Documentation/usb/hotplug.txt drivers/net/usb/usbnet.c drivers/usb/core/hcd.c drivers/usb/host/ohci-hcd.c drivers/usb/host/xhci.c Signed-off-by: NPetr Mladek <pmladek@suse.cz> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 09 9月, 2014 1 次提交
-
-
由 Felipe Balbi 提交于
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) implemented a workaround for a known issue with Texas Instruments' USB 3.0 redriver IC but it left a condition where any xHCI host would be taken out of reset if port was placed in compliance mode and there was no device connected to the port. That condition would trigger a fake connection to a non-existent device so that usbcore would trigger a warm reset of the port, thus taking the link out of reset. This has the side-effect of preventing any xHCI host connected to a Linux machine from starting and running the USB 3.0 Electrical Compliance Suite because the port will mysteriously taken out of compliance mode and, thus, xHCI won't step through the necessary compliance patterns for link validation. This patch fixes the issue by just adding a missing check for XHCI_COMP_MODE_QUIRK inside xhci_hub_report_usb3_link_state() when PORT_CAS isn't set. This patch should be backported to all kernels containing commit 71c731a2. Fixes: 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVP3502CP Hardware) Cc: Alexis R. Cortes <alexis.cortes@ti.com> Cc: <stable@vger.kernel.org> # v3.2+ Signed-off-by: NFelipe Balbi <balbi@ti.com> Acked-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 6月, 2014 1 次提交
-
-
由 Lu Baolu 提交于
When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend, xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel platforms may get a spurious wakeup, even if PCI PME# is disabled. This patch should be back-ported to kernels as old as 2.6.37, that contains the commit 9777e3ce "USB: xHCI: bus power management implementation". Cc: stable@vger.kernel.org # 2.6.37 Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 6月, 2014 1 次提交
-
-
由 Mathias Nyman 提交于
xhci_stop_device() allocates and issues stop commands for each active endpoint. This is done with spinlock held and interrupt disabled so we can't sleep during memory allocation. Use GFP_NOWAIT instead Regression from commit ddba5cd0 "xhci: Use command structures when queuing commands on the command ring" for 3.16-rc1 Fixes: ddba5cd0 ("xhci: Use command structures when queuing commands") Reported-by: NDan Williams <dan.j.williams@intel.com> Reported-by: NJohannes Berg <johannes@sipsolutions.net> Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 20 5月, 2014 3 次提交
-
-
由 Mathias Nyman 提交于
Use one timer to control command timeout. start/kick the timer every time a command is completed and a new command is waiting, or a new command is added to a empty list. If the timer runs out, then tag the current command as "aborted", and start the xhci command abortion process. Previously each function that submitted a command had its own timer. If that command timed out, a new command structure for the command was created and it was put on a cancel_cmd_list list, then a pci write to abort the command ring was issued. when the ring was aborted, it checked if the current command was the one to be canceled, later when the ring was stopped the driver got ownership of the TRBs in the command ring, compared then to the TRBs in the cancel_cmd_list, and turned them into No-ops. Now, instead, at timeout we tag the status of the command in the command queue to be aborted, and start the ring abortion. Ring abortion stops the command ring and gives control of the commands to us. All the aborted commands are now turned into No-ops. If the ring is already stopped when the command times outs its not possible to start the ring abortion, in this case the command is turnd to No-op right away. All these changes allows us to remove the entire cancel_cmd_list code. The functions waiting for a command to finish no longer have their own timeouts. They will wait either until the command completes normally, or until the whole command abortion is done. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
Remove the per-device command list and handle_cmd_in_cmd_wait_list() and use the completion and status variables found in the command structure in the global command list. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mathias Nyman 提交于
To create a global command queue we require that each command put on the command ring is submitted with a command structure. Functions that queue commands and wait for completion need to allocate a command before submitting it, and free it once completed. The following command queuing functions need to be modified. xhci_configure_endpoint() xhci_address_device() xhci_queue_slot_control() xhci_queue_stop_endpoint() xhci_queue_new_dequeue_state() xhci_queue_reset_ep() xhci_configure_endpoint() xhci_configure_endpoint() could already be called with a command structure, and only xhci_check_maxpacket and xhci_check_bandwidth did not do so. These are changed and a command structure is now required. This change also simplifies the configure endpoint command completion handling and the "goto bandwidth_change" handling code can be removed. In some cases the command queuing function is called in interrupt context. These commands needs to be allocated atomically, and they can't wait for completion. These commands will in this patch be freed directly after queuing, but freeing will be moved to the command completion event handler in a later patch once we get the global command queue up.(Just so that we won't leak memory in the middle of the patch set) Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 05 3月, 2014 1 次提交
-
-
由 Sarah Sharp 提交于
The xHCI driver currently uses a USB core internal field, udev->lpm_capable, to indicate the xHCI driver knows how to calculate the LPM timeout values. If this value is set for the host controller udev, it means Link PM can be enabled for child devices under that host. Change the code so the xHCI driver isn't mucking with USB core internal fields. Instead, indicate the xHCI driver doesn't support Link PM on this host by clearing the U1 and U2 exit latencies in the roothub SuperSpeed Extended Capabilities BOS descriptor. The code to check for the roothub setting U1 and U2 exit latencies to zero will also disable LPM for external devices that do that same. This was already effectively done with commit ae8963ad "usb: Don't enable LPM if the exit latency is zero." Leave that code in place, so that if a device sets one exit latency value to zero, but the other is set to a valid value, LPM is only enabled for the U1 or U2 state that had the valid value. This is the same behavior the code had before. Also, change messages about missing Link PM information from warning level to info level. Only print a warning about the first device that doesn't support LPM, to avoid log spam. Further, cleanup some unnecessary line breaks to help people to grep for the error messages. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
-
- 03 12月, 2013 2 次提交
-
-
由 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>
-
- 17 10月, 2013 1 次提交
-
-
由 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>
-