- 31 8月, 2013 1 次提交
-
-
由 Alan Stern 提交于
This patch fixes a build error that occurs when CONFIG_PM is enabled and CONFIG_PM_SLEEP isn't: >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function) .pm = &usb_hcd_pci_pm_ops Since the usb_hcd_pci_pm_ops structure is defined and used when CONFIG_PM is enabled, its declaration should not be protected by CONFIG_PM_SLEEP. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Reported-by: Nkbuild test robot <fengguang.wu@intel.com> CC: <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 8月, 2013 1 次提交
-
-
由 Ming Lei 提交于
This patch implements the mechanism of giveback of URB in tasklet context, so that hardware interrupt handling time for usb host controller can be saved much, and HCD interrupt handling can be simplified. Motivations: 1), on some arch(such as ARM), DMA mapping/unmapping is a bit time-consuming, for example: when accessing usb mass storage via EHCI on pandaboard, the common length of transfer buffer is 120KB, the time consumed on DMA unmapping may reach hundreds of microseconds; even on A15 based box, the time is still about scores of microseconds 2), on some arch, reading DMA coherent memoery is very time-consuming, the most common example is usb video class driver[1] 3), driver's complete() callback may do much things which is driver specific, so the time is consumed unnecessarily in hardware irq context. 4), running driver's complete() callback in hardware irq context causes that host controller driver has to release its lock in interrupt handler, so reacquiring the lock after return may busy wait a while and increase interrupt handling time. More seriously, releasing the HCD lock makes HCD becoming quite complicated to deal with introduced races. So the patch proposes to run giveback of URB in tasklet context, then time consumed in HCD irq handling doesn't depend on drivers' complete and DMA mapping/unmapping any more, also we can simplify HCD since the HCD lock isn't needed to be released during irq handling. The patch should be reasonable and doable: 1), for drivers, they don't care if the complete() is called in hard irq context or softirq context 2), the biggest change is the situation in which usb_submit_urb() is called in complete() callback, so the introduced tasklet schedule delay might be a con, but it shouldn't be a big deal: - control/bulk asynchronous transfer isn't sensitive to schedule delay - the patch schedules giveback of periodic URBs using tasklet_hi_schedule, so the introduced delay should be very small - for ISOC transfer, generally, drivers submit several URBs concurrently to avoid interrupt delay, so it is OK with the little schedule delay. - for interrupt transfer, generally, drivers only submit one URB at the same time, but interrupt transfer is often used in event report, polling, ... situations, and a little delay should be OK. Considered that HCDs may optimize on submitting URB in complete(), the patch may cause the optimization not working, so introduces one flag to mark if the HCD supports to run giveback URB in tasklet context. When all HCDs are ready, the flag can be removed. [1], http://marc.info/?t=136438111600010&r=1&w=2 Cc: Oliver Neukum <oliver@neukum.org> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NMing Lei <ming.lei@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 04 6月, 2013 1 次提交
-
-
由 Thomas Pugliese 提交于
This patch adds Wireless USB root hub support to the USB HCD. It allows the HWA to create its root hub which previously failed because the HCD treated wireless root hubs the same as USB2 high speed hubs. The creation of the root hub would fail in that case due to lack of TTs which wireless root hubs do not support. Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 3月, 2013 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially replacing it everywhere with CONFIG_PM_RUNTIME (except for one place in hub.c, where it is replaced with CONFIG_PM because the code needs to be used in both runtime and system PM). The net result is code shrinkage and simplification. There's very little point in keeping CONFIG_USB_SUSPEND because almost everybody enables it. The few that don't will find that the usbcore module has gotten somewhat bigger and they will have to take active measures if they want to prevent hubs from being runtime suspended. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 26 3月, 2013 1 次提交
-
-
由 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: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 26 1月, 2013 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1649) adds a mechanism for host controller drivers to inform usbcore when they have begun or ended resume signalling on a particular root-hub port. The core will then make sure that the root hub does not get runtime-suspended while the port resume is going on. Since commit 596d789a (USB: set hub's default autosuspend delay as 0), the system tries to suspend hubs whenever they aren't in use. While a root-hub port is being resumed, the root hub does not appear to be in use. Attempted runtime suspends fail because of the ongoing port resume, but the PM core just keeps on trying over and over again. We want to prevent this wasteful effort. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NMing Lei <ming.lei@canonical.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 17 8月, 2012 1 次提交
-
-
由 Kishon Vijay Abraham I 提交于
Changed the type of rsrc_start and rsrc_len from u64 to resource_size_t so that it behaves well with resource API's like *resource_size()* on both 32bit and 64bit devices. Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 14 6月, 2012 2 次提交
-
-
由 Alan Stern 提交于
This patch (as1558) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. A similar patch has already been applied as commit 151b6128 (USB: EHCI: fix crash during suspend on ASUS computers). The patch supersedes that one and reverts it. There are two differences: The old patch added the flag at the USB level; this patch adds it at the PCI level. The old patch applied to all chipsets with the same vendor, subsystem vendor, and product IDs; this patch makes an exception for a known-good system (based on DMI information). Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NDâniel Fraga <fragabr@gmail.com> Tested-by: NAndrey Rahmatullin <wrar@wrar.name> Tested-by: NSteven Rostedt <rostedt@goodmis.org> Cc: stable <stable@vger.kernel.org> Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Richard Zhao 提交于
- to decrease redundant since both ehci_hcd and ohci_hcd have the same variable - it helps access phy in usb core code - phy is more meaningful than transceiver Signed-off-by: NRichard Zhao <richard.zhao@freescale.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 19 5月, 2012 1 次提交
-
-
由 Sarah Sharp 提交于
There are various functions within the USB core that will need to disable USB 3.0 link power states. For example, when a USB device driver is being bound to an interface, we need to disable USB 3.0 LPM until we know if the driver will allow hub-initiated LPM transitions. Another example is when the USB core is switching alternate interface settings. The USB 3.0 timeout values are dependent on what endpoints are enabled, so we want to ensure that LPM is disabled until the new alt setting is fully installed. Multiple functions need to disable LPM, and those functions can even be nested. For example, usb_bind_interface() could disable LPM, and then call into the driver probe function, which may attempt to switch to a different alt setting. Therefore, we need to keep a count of the number of functions that require LPM to be disabled at any point in time. Introduce two new USB core API calls, usb_disable_lpm() and usb_enable_lpm(). These functions increment and decrement a new variable in the usb_device, lpm_disable_count. If usb_disable_lpm() fails, it will call usb_enable_lpm() in order to balance the lpm_disable_count. These two new functions must be called with the bandwidth_mutex locked. If the bandwidth_mutex is not already held by the caller, it should instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take the bandwidth_mutex before calling usb_disable_lpm() and usb_enable_lpm(), respectively. Introduce a new variable (timeout) in the usb3_lpm_params structure to keep track of the currently enabled U1/U2 timeout values. When usb_disable_lpm() is called, and the USB device has the U1 or U2 timeouts set to a non-zero value (meaning either device-initiated or hub-initiated LPM is enabled), attempt to disable LPM, regardless of the state of the lpm_disable_count. We want to ensure that all callers can be guaranteed that LPM is disabled if usb_disable_lpm() returns zero. Otherwise the following scenario could occur: 1. Driver A is being bound to interface 1. usb_probe_interface() disables LPM. Driver A doesn't care if hub-initiated LPM is enabled, so even though usb_disable_lpm() fails, the probe of the driver continues, and the bandwidth mutex is dropped. 2. Meanwhile, Driver B is being bound to interface 2. usb_probe_interface() grabs the bandwidth mutex and calls usb_disable_lpm(). That call should attempt to disable LPM, even though the lpm_disable_count is set to 1 by Driver A. For usb_enable_lpm(), we attempt to enable LPM only when the lpm_disable_count is zero. If some step in enabling LPM fails, it will only have a minimal impact on power consumption, and all USB device drivers should still work properly. Therefore don't bother to return any error codes. Don't enable device-initiated LPM if the device is unconfigured. The USB device will only accept the U1/U2_ENABLE control transfers in the configured state. Do enable hub-initiated LPM in that case, since devices are allowed to accept the LGO_Ux link commands in any state. Don't enable or disable LPM if the device is marked as not being LPM capable. This can happen if: - the USB device doesn't have a SS BOS descriptor, - the device's parent hub has a zeroed bHeaderDecodeLatency value, or - the xHCI host doesn't support LPM. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 30 4月, 2012 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
This option has been deprecated for many years now, and no userspace tools use it anymore, so it should be safe to finally remove it. Reported-by: NKay Sievers <kay@vrfy.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 4月, 2012 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1545) fixes a problem affecting several ASUS computers: The machine crashes or corrupts memory when going into suspend if the ehci-hcd driver is bound to any controllers. Users have been forced to unbind or unload ehci-hcd before putting their systems to sleep. After extensive testing, it was determined that the machines don't like going into suspend when any EHCI controllers are in the PCI D3 power state. Presumably this is a firmware bug, but there's nothing we can do about it except to avoid putting the controllers in D3 during system sleep. The patch adds a new flag to indicate whether the problem is present, and avoids changing the controller's power state if the flag is set. Runtime suspend is unaffected; this matters only for system suspend. However as a side effect, the controller will not respond to remote wakeup requests while the system is asleep. Hence USB wakeup is not functional -- but of course, this is already true in the current state of affairs. This fixes Bugzilla #42728. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NSteven Rostedt <rostedt@goodmis.org> Tested-by: NAndrey Rahmatullin <wrar@wrar.name> Tested-by: NOleksij Rempel (fishor) <bug-track@fisher-privat.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 02 3月, 2012 1 次提交
-
-
由 Felipe Balbi 提交于
There's really no point in having hcd->irq as a signed integer when we consider the fact that IRQ 0 means NO_IRQ. In order to avoid confusion, make hcd->irq unsigned and fix users who were passing -1 as the IRQ number to usb_add_hcd. Tested-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 2月, 2012 1 次提交
-
-
由 Sarah Sharp 提交于
USB 3.0 hubs don't have a port suspend change bit (that bit is now reserved). Instead, when a host-initiated resume finishes, the hub sets the port link state change bit. When a USB 3.0 device initiates remote wakeup, the parent hubs with their upstream links in U3 will pass the LFPS up the chain. The first hub that has an upstream link in U0 (which may be the roothub) will reflect that LFPS back down the path to the device. However, the parent hubs in the resumed path will not set their link state change bit. Instead, the device that initiated the resume has to send an asynchronous "Function Wake" Device Notification up to the host controller. Therefore, we need a way to notify the USB core of a device resume without going through the normal hub URB completion method. First, make the xHCI roothub act like an external USB 3.0 hub and not pass up the port link state change bit when a device-initiated resume finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that we can tell the difference between a port coming out of the U3Exit state (host-initiated resume) and the RExit state (ending state of device-initiated resume). Since the USB core can't tell whether a port on a hub has resumed by looking at the Hub Status buffer, we need to introduce a bitfield, wakeup_bits, that indicates which ports have resumed. When the xHCI driver notices a port finishing a device-initiated resume, we call into a new USB core function, usb_wakeup_notification(), that will set the right bit in wakeup_bits, and kick khubd for that hub. We also call usb_wakeup_notification() when the Function Wake Device Notification is received by the xHCI driver. This covers the case where the link between the roothub and the first-tier hub is in U0, and the hub reflects the resume signaling back to the device without giving any indication it has done so until the device sends the Function Wake notification. Change the code in khubd that handles the remote wakeup to look at the state the USB core thinks the device is in, and handle the remote wakeup if the port's wakeup bit is set. This patch only takes care of the case where the device is attached directly to the roothub, or the USB 3.0 hub that is attached to the root hub is the device sending the Function Wake Device Notification (e.g. because a new USB device was attached). The other cases will be covered in a second patch. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
- 15 11月, 2011 1 次提交
-
-
由 Alan Stern 提交于
The HCD_FLAG_SAW_IRQ flag was introduced in order to catch IRQ routing errors: If an URB was unlinked and the host controller hadn't gotten any IRQs, it seemed likely that the IRQs were directed to the wrong vector. This warning hasn't come up in many years, as far as I know; interrupt routing now seems to be well under control. Therefore there's no reason to keep the flag around any more. This patch (as1495) finally removes it. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 11 10月, 2011 1 次提交
-
-
由 Harro Haan 提交于
The Kirkwood gave an unaligned memory access error on line 742 of drivers/usb/host/echi-hcd.c: "ehci->last_periodic_enable = ktime_get_real();" Signed-off-by: NHarro Haan <hrhaan@gmail.com> Cc: stable <stable@kernel.org> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 27 9月, 2011 1 次提交
-
-
由 Andiry Xu 提交于
If the device pass the USB2 software LPM and the host supports hardware LPM, enable hardware LPM for the device to let the host decide when to put the link into lower power state. If hardware LPM is enabled for a port and driver wants to put it into suspend, it must first disable hardware LPM, resume the port into U0, and then suspend the port. Signed-off-by: NAndiry Xu <andiry.xu@amd.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 14 3月, 2011 4 次提交
-
-
由 Sarah Sharp 提交于
Introduce the notion of a PCI device that may be associated with more than one USB host controller driver (struct usb_hcd). This patch is the start of the work to separate the xHCI host controller into two roothubs: a USB 3.0 roothub with SuperSpeed-only ports, and a USB 2.0 roothub with HS/FS/LS ports. One usb_hcd structure is designated to be the "primary HCD", and a pointer is added to the usb_hcd structure to keep track of that. A new function call, usb_hcd_is_primary_hcd() is added to check whether the USB hcd is marked as the primary HCD (or if it is not part of a roothub pair). To allow the USB core and xHCI driver to access either roothub in a pair, a "shared_hcd" pointer is added to the usb_hcd structure. Add a new function, usb_create_shared_hcd(), that does roothub allocation for paired roothubs. It will act just like usb_create_hcd() did if the primary_hcd pointer argument is NULL. If it is passed a non-NULL primary_hcd pointer, it sets usb_hcd->shared_hcd and usb_hcd->primary_hcd fields. It will also skip the bandwidth_mutex allocation, and set the secondary hcd's bandwidth_mutex pointer to the primary HCD's mutex. IRQs are only allocated once for the primary roothub. Introduce a new usb_hcd driver flag that indicates the host controller driver wants to create two roothubs. If the HCD_SHARED flag is set, then the USB core PCI probe methods will allocate a second roothub, and make sure that second roothub gets freed during rmmod and in initialization error paths. When usb_hc_died() is called with the primary HCD, make sure that any roothubs that share that host controller are also marked as being dead. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
The xHCI driver essentially has both a USB 2.0 and a USB 3.0 roothub. So setting the HCD_USB3 bits in the hcd->driver->flags is a bit misleading. Add a new field to usb_hcd, bcdUSB. Store the result of hcd->driver->flags & HCD_MASK in it. Later, when we have the xHCI driver register the two roothubs, we'll set the usb_hcd->bcdUSB field to HCD_USB2 for the USB 2.0 roothub, and HCD_USB3 for the USB 3.0 roothub. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
Change the bandwith_mutex in struct usb_hcd to a pointer. This will allow the pointer to be shared across usb_hcds for the upcoming work to split the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
Using a #define to redefine a common variable name is a bad thing, especially when the #define is in a header. include/linux/usb/hcd.h redefined bitmap to DeviceRemovable to avoid typing a long field in the hub descriptor. This has unintended side effects for files like drivers/usb/core/devio.c that include that file, since another header included after hcd.h has different variables named bitmap. Remove the bitmap #define and replace instances of it in the host controller code. Cleanup the spaces around function calls and square brackets while we're at it. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: Tony Olech <tony.olech@elandigitalsystems.com> Cc: "Robert P. J. Day" <rpjday@crashcourse.ca> Cc: Max Vozeler <mvz@vozeler.com> Cc: Tejun Heo <tj@kernel.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Rodolfo Giometti <giometti@linux.it> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Anton Vorontsov <avorontsov@mvista.com> Cc: Sebastian Siewior <bigeasy@linutronix.de> Cc: Lothar Wassmann <LW@KARO-electronics.de> Cc: Olav Kongas <ok@artecdesign.ee> Cc: Martin Fuzzey <mfuzzey@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <dbrownell@users.sourceforge.net>
-
- 08 3月, 2011 1 次提交
-
-
由 Alan Stern 提交于
The hcd->state variable is a disaster. It's not clearly owned by either usbcore or the host controller drivers, and they both change it from time to time, potentially stepping on each other's toes. It's not protected by any locks. And there's no mechanism to prevent it from going through an invalid transition. This patch (as1451) takes a first step toward fixing these problems. As it turns out, usbcore uses hcd->state for essentially only two things: checking whether the controller's root hub is running and checking whether the controller has died. Therefore the patch adds two new atomic bitflags to the hcd structure, to store these pieces of information. The new flags are used only by usbcore, and a private spinlock prevents invalid combinations (a dead controller's root hub cannot be running). The patch does not change the places where usbcore sets hcd->state, since HCDs may depend on them. Furthermore, there is one place in usb_hcd_irq() where usbcore still must use hcd->state: An HCD's interrupt handler can implicitly indicate that the controller died by setting hcd->state to HC_STATE_HALT. Nevertheless, the new code is a big improvement over the current code. The patch makes one other change. The hcd_bus_suspend() and hcd_bus_resume() routines now check first whether the host controller has died; if it has then they return immediately without calling the HCD's bus_suspend or bus_resume methods. This fixes the major problem reported in Bugzilla #29902: The system fails to suspend after a host controller dies during system resume. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NAlex Terekhov <a.terekhov@gmail.com> CC: <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 05 2月, 2011 2 次提交
-
-
由 Robert Morell 提交于
Provide optional hooks for the host controller driver to override the default DMA mapping and unmapping routines. In general, these shouldn't be necessary unless the host controller has special DMA requirements, such as alignment contraints. If these are not specified, the general usb_hcd_(un)?map_urb_for_dma functions will be used instead. Also, pass the status to unmap_urb_for_dma so it can know whether the DMA buffer has been overwritten. Finally, add a flag to be used by these implementations if they allocated a temporary buffer so it can be freed properly when unmapping. Signed-off-by: NRobert Morell <rmorell@nvidia.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Robert Morell 提交于
The convention is to prefix symbols exported from the USB HCD core with "usb_hcd". This change makes unmap_urb_setup_for_dma() and unmap_urb_for_dma() consistent with that. Signed-off-by: NRobert Morell <rmorell@nvidia.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 15 1月, 2011 1 次提交
-
-
由 Andiry Xu 提交于
Synchronize the interrupts instead of free them in xhci_suspend(). This will prevent a double free when the host is suspended and then the card removed. Set the flag hcd->msix_enabled when using MSI-X, and check the flag in suspend_common(). MSI-X synchronization will be handled by xhci_suspend(), and MSI/INTx will be synchronized in suspend_common(). This patch should be queued for the 2.6.37 stable tree. Reported-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NAndiry Xu <andiry.xu@amd.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
-
- 11 11月, 2010 1 次提交
-
-
由 Tatyana Brokhman 提交于
Adding hub SuperSpeed usb definitions as defined by ch10 of the USB3.0 spec. Signed-off-by: NTatyana Brokhman <tlinder@codeaurora.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 10月, 2010 2 次提交
-
-
由 Martin Fuzzey 提交于
Split unmap_urb_for_dma() to allow just the setup buffer to be unmapped. This allows HCDs to use PIO for the setup buffer if it is not suitable for DMA. Signed-off-by: NMartin Fuzzey <mfuzzey@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Maulik Mankad 提交于
The USB stack maps the buffer for DMA if the controller supports DMA. MUSB controller can perform DMA as well as PIO transfers. The buffer needs to be unmapped before CPU can perform PIO data transfers. Export unmap_urb_for_dma() so that drivers can perform the DMA unmapping in a sane way. Signed-off-by: NMaulik Mankad <x0082077@ti.com> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 11 8月, 2010 5 次提交
-
-
由 Alan Stern 提交于
This patch (as1395) adds code to hcd_pci_suspend() for handling wakeup races. This is another general race pattern, similar to the "open vs. unregister" race we're all familiar with. Here, the race is between suspending a device and receiving a wakeup request from one of the device's suspended children. In particular, if a root-hub wakeup is requested at about the same time as the corresponding USB controller is suspended, and if the controller is enabled for wakeup, then the controller should either fail to suspend or else wake right back up again. During system sleep this won't happen very much, especially since host controllers generally aren't enabled for wakeup during sleep. However it is definitely an issue for runtime PM. Something like this will be needed to prevent the controller from autosuspending while waiting for a root-hub resume to take place. (That is, in fact, the common case, for which there is an extra test.) Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
This patch (as1385) adds a "do_wakeup" parameter to the pci_suspend method used by PCI-based host controller drivers. ehci-hcd in particular needs to know whether or not to enable wakeup when suspending a controller. Although that information is currently available through device_may_wakeup(), when support is added for runtime suspend this will no longer be true. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
This patch (as1393) converts several of the single-bit fields in struct usb_hcd to atomic flags. This is for safety's sake; not all CPUs can update bitfield values atomically, and these flags are used in multiple contexts. The flag fields that are set only during registration or removal can remain as they are, since non-atomic accesses at those times will not cause any problems. (Strictly speaking, the authorized_default flag should become atomic as well. I didn't bother with it because it gets changed only via sysfs. It can be done later, if anyone wants.) Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alek Du 提交于
With this patch, the LPM capable EHCI host controller can put device into L1 sleep state which is a mode that can enter/exit quickly, and reduce power consumption. Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com> Signed-off-by: NAlek Du <alek.du@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
This patch (as1390) fixes a problem that crops up when a UHCI host controller is unbound from uhci-hcd while there are still some active URBs. The URBs have to be unlinked when the root hub is unregistered, and uhci-hcd relies upon root-hub status polls as part of its unlinking procedure. But usb_hcd_poll_rh_status() won't make those status calls if hcd->rh_registered is clear, and the flag is cleared _before_ the unregistration takes place. Since hcd->rh_registered is used for other things and needs to be cleared early, the solution is to add a new flag (rh_pollable) and use it instead. It gets cleared _after_ the root hub is unregistered. Now that the status polls don't end too soon, we have to make sure they also don't occur too late -- after the root hub's usb_device structure or the HCD's private structures are deallocated. Therefore the patch adds usb_get_device() and usb_put_device() calls to protect the root hub structure, and it adds an extra del_timer_sync() to prevent the root-hub timer from causing an unexpected status poll. This additional complexity would not be needed if the HCD framework had provided separate stop() and release() callbacks instead of just stop(). This lack could be fixed at some future time (although it would require changes to every host controller driver); when that happens this patch won't be needed any more. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 21 5月, 2010 5 次提交
-
-
由 Greg Kroah-Hartman 提交于
Lots of minor formatting cleanups in includes/usb/ to make checkpatch happier. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Sarah Sharp 提交于
Bulk endpoint streams were added in the USB 3.0 specification. Streams allow a device driver to overload a bulk endpoint so that multiple transfers can be queued at once. The device then decides which transfer it wants to work on first, and can queue part of a transfer before it switches to a new stream. All this switching is invisible to the device driver, which just gets a completion for the URB. Drivers that use streams must be able to handle URBs completing in a different order than they were submitted to the endpoint. This requires adding new API to set up xHCI data structures to support multiple queues ("stream rings") per endpoint. Drivers will allocate a number of stream IDs before enqueueing URBs to the bulk endpoints of the device, and free the stream IDs in their disconnect function. See Documentation/usb/bulk-streams.txt for details. The new mass storage device class, USB Attached SCSI Protocol (UASP), uses these streams API. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Eric Lescouet 提交于
Base on inputs from Alan Stern, split the hub.h header into: - new ch11.h header (most of it) containing constants and structures from chapter 11 of the USB 2.0 spec. - a small remaining part being merged into hcd.h. Signed-of-by: NEric Lescouet <eric@lescouet.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Eric Lescouet 提交于
The usbcore headers: hcd.h and hub.h are shared between usbcore, HCDs and a couple of other drivers (e.g. USBIP modules). So, it makes sense to move them into a more public location and to cleanup dependency of those modules on kernel internal headers. This patch moves hub.h from drivers/usb/core into include/linux/usb/ Signed-of-by: NEric Lescouet <eric@lescouet.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Eric Lescouet 提交于
The usbcore headers: hcd.h and hub.h are shared between usbcore, HCDs and a couple of other drivers (e.g. USBIP modules). So, it makes sense to move them into a more public location and to cleanup dependency of those modules on kernel internal headers. This patch moves hcd.h from drivers/usb/core into include/linux/usb/ Signed-of-by: NEric Lescouet <eric@lescouet.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 03 3月, 2010 2 次提交
-
-
由 Herbert Xu 提交于
USB: Move hcd free_dev call into usb_disconnect I found a way to oops the kernel: 1. Open a USB device through devio. 2. Remove the hcd module in the host kernel. 3. Close the devio file descriptor. The problem is that closing the file descriptor does usb_release_dev as it is the last reference. usb_release_dev then tries to invoke the hcd free_dev function (or rather dereferencing the hcd driver struct). This causes an oops as the hcd driver has already been unloaded so the struct is gone. This patch tries to fix this by bringing the free_dev call earlier and into usb_disconnect. I have verified that repeating the above steps no longer crashes with this patch applied. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Alan Stern 提交于
This patch (as1329) converts the USB stack over to the PM core's runtime PM framework. This involves numerous changes throughout usbcore, especially to hub.c and driver.c. Perhaps the most notable change is that CONFIG_USB_SUSPEND now depends on CONFIG_PM_RUNTIME instead of CONFIG_PM. Several fields in the usb_device and usb_interface structures are no longer needed. Some code which used to depend on CONFIG_USB_PM now depends on CONFIG_USB_SUSPEND (requiring some rearrangement of header files). The only visible change in behavior should be that following a system sleep (resume from RAM or resume from hibernation), autosuspended USB devices will be resumed just like everything else. They won't remain suspended. But if they aren't in use then they will naturally autosuspend again in a few seconds. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-