- 19 5月, 2012 8 次提交
-
-
由 Sarah Sharp 提交于
There are several places where the USB core needs to disable USB 3.0 Link PM: - usb_bind_interface - usb_unbind_interface - usb_driver_claim_interface - usb_port_suspend/usb_port_resume - usb_reset_and_verify_device - usb_set_interface - usb_reset_configuration - usb_set_configuration Use the new LPM disable/enable functions to temporarily disable LPM around these critical sections. We need to protect the critical section around binding and unbinding USB interface drivers. USB drivers may want to disable hub-initiated USB 3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI driver will install. We need to disable LPM completely until the driver is bound to the interface, and the driver has a chance to enable whatever alternate interface setting it needs in its probe routine. Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values. We also need to disable LPM in usb_driver_claim_interface, because drivers like usbfs can bind to an interface through that function. Note, there is no way currently for userspace drivers to disable hub-initiated USB 3.0 LPM. Revisit this later. When a driver is unbound, the U1/U2 timeouts may change because we are unbinding the last driver that needed hub-initiated USB 3.0 LPM to be disabled. USB LPM must be disabled when a USB device is going to be suspended. The USB 3.0 spec does not define a state transition from U1 or U2 into U3, so we need to bring the device into U0 by disabling LPM before we can place it into U3. Therefore, call usb_unlocked_disable_lpm() in usb_port_suspend(), and call usb_unlocked_enable_lpm() in usb_port_resume(). If the port suspend fails, make sure to re-enable LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will not be called on a failed port suspend. USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB device-initiated LPM is enabled) across device suspend. Therefore, disable LPM before the device will be reset in usb_reset_and_verify_device(), and re-enable LPM after the reset is complete and the configuration/alt settings are re-installed. The calculated U1/U2 timeout values are heavily dependent on what USB device endpoints are currently enabled. When any of the enabled endpoints on the device might change, due to a new configuration, or new alternate interface setting, we need to first disable USB 3.0 LPM, add or delete endpoints from the xHCI schedule, install the new interfaces and alt settings, and then re-enable LPM. Do this in usb_set_interface, usb_reset_configuration, and usb_set_configuration. Basically, there is a call to disable and then enable LPM in all functions that lock the bandwidth_mutex. One exception is usb_disable_device, because the device is disconnecting or otherwise going away, and we should not care about whether USB 3.0 LPM is enabled. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 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>
-
由 Sarah Sharp 提交于
There are several different exit latencies associated with coming out of the U1 or U2 lower power link state. Device Exit Latency (DEL) is the maximum time it takes for the USB device to bring its upstream link into U0. That can be found in the SuperSpeed Extended Capabilities BOS descriptor for the device. The time it takes for a particular link in the tree to exit to U0 is the maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL. Hubs introduce a further delay that effects how long it takes a child device to transition to U0. When a USB 3.0 hub receives a header packet, it takes some time to decode that header and figure out which downstream port the packet was destined for. If the port is not in U0, this hub header decode latency will cause an additional delay for bringing the child device to U0. This Hub Header Decode Latency is found in the USB 3.0 hub descriptor. We can use DEL and the header decode latency, along with additional latencies imposed by each additional hub tier, to figure out the exit latencies for both host-initiated and device-initiated exit to U0. The Max Exit Latency (MEL) is the worst-case time it will take for a host-initiated exit to U0, based on whether U1 or U2 link states are enabled. The ping or packet must traverse the path to the device, and each hub along the way incurs the hub header decode latency in order to figure out which device the transfer was bound for. We say worst-case, because some hubs may not be in the lowest link state that is enabled. See the examples in section C.2.2.1. Note that "HSD" is a "host specific delay" that the power appendix architect has not been able to tell me how to calculate. There's no way to get HSD from the xHCI registers either, so I'm simply ignoring it. The Path Exit Latency (PEL) is the worst-case time it will take for a device-initiate exit to U0 to place all the links from the device to the host into U0. The System Exit Latency (SEL) is another device-initiated exit latency. SEL is useful for USB 3.0 devices that need to send data to the host at specific intervals. The device may send an NRDY to indicate it isn't ready to send data, then put its link into a lower power state. If it needs to have that data transmitted at a specific time, it can use SEL to back calculate when it will need to bring the link back into U0 to meet its deadlines. SEL is the worst-case time from the device-initiated exit to U0, to when the device will receive a packet from the host controller. It includes PEL, the time it takes for an ERDY to get to the host, a host-specific delay for the host to process that ERDY, and the time it takes for the packet to traverse the path to the device. See Figure C-2 in the USB 3.0 bus specification. Note: I have not been able to get good answers about what the host-specific delay to process the ERDY should be. The Intel HW developers say it will be specific to the platform the xHCI host is integrated into, and they say it's negligible. Ignore this too. Separate from these four exit latencies are the U1/U2 timeout values we program into the parent hubs. These timeouts tell the hub to attempt to place the device into a lower power link state after the link has been idle for that amount of time. Create two arrays (one for U1 and one for U2) to store mel, pel, sel, and the timeout values. Store the exit latency values in nanosecond units, since that's the smallest units used (DEL is in us, but the Hub Header Decode Latency is in ns). If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS descriptor, it's highly unlikely it will be able to handle LPM requests properly. So it's best to disable LPM for devices that don't have this descriptor, and any children beneath it, if it's a USB 3.0 hub. Warn users when that happens, since it means they have a non-compliant USB 3.0 device or hub. This patch assumes a simplified design where links deep in the tree will not have U1 or U2 enabled unless all their parent links have the corresponding LPM state enabled. Eventually, we might want to allow a different policy, and we can revisit this patch when that happens. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu>
-
由 Sarah Sharp 提交于
Refactor the code that sets the usb_device flag to indicate the device support link power management (lpm_capable). The current code sets lpm_capable unconditionally if the USB devices have a USB 2.0 Extended Capabilities Descriptor. USB 3.0 devices can also have that descriptor, but the xHCI driver code that uses lpm_capable will not run the USB 2.0 LPM test for devices under the USB 3.0 roothub. Therefore, it's fine only set lpm_capable for high speed devices in this refactoring. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
The BOS descriptor is normally fetched and stored in the usb_device->bos during enumeration. USB 3.0 roothubs don't undergo enumeration, but we need them to have a BOS descriptor, since each xHCI host has a different U1 and U2 exit latency. Make sure to fetch the BOS descriptor for USB 3.0 roothubs. It will be freed when the roothub usb_device is released. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: Andiry Xu <andiry.xu@amd.com>
-
由 Sarah Sharp 提交于
USB 3.0 hubs can be put into a mode where the hub can automatically request that the link go into a deeper link power state after the link has been idle for a specified amount of time. Each of the new USB 3.0 link states (U1 and U2) have their own timeout that can be programmed per port. Change the xHCI roothub emulation code to handle the request to set the U1 and U2 timeouts. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Sarah Sharp 提交于
When the xHCI driver needs to clean up memory (perhaps due to a failed register restore on resume from S3 or resume from S4), it needs to reset the number of reserved TRBs on the command ring to zero. Otherwise, several resume cycles (about 30) with a UAS device attached will continually increment the number of reserved TRBs, until all command submissions fail because there isn't enough room on the command ring. This patch should be backported to kernels as old as 2.6.32, that contain the commit 913a8a34 "USB: xhci: Change how xHCI commands are handled." Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
由 Oliver Neukum 提交于
Some more data structures must be freed and counters reset if an XHCI controller has lost power. The failure to do so renders some chips inoperative after a certain number of S4 cycles. This patch should be backported to kernels as old as 3.2, that contain the commits c29eea62 "xhci: Implement HS/FS/LS bandwidth checking." and commit 839c817c "xhci: Implement HS/FS/LS bandwidth checking." Signed-off-by: NOliver Neukum <oneukum@suse.de> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
- 18 5月, 2012 5 次提交
-
-
由 Andiry Xu 提交于
USB2 LPM is disabled when device begin to suspend and enabled after device is resumed. That's because USB spec does not define the transition from U1/U2 state to U3 state. If usb_port_suspend() fails, usb_port_resume() is never called, and USB2 LPM is disabled in this situation. Enable USB2 LPM if port suspend fails. This patch should be backported to kernels as old as 3.2, that contain the commit 65580b43 "xHCI: set USB2 hardware LPM". Signed-off-by: NAndiry Xu <andiry.xu@gmail.com> Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
由 Sarah Sharp 提交于
Sergio reported that when he recorded audio from a USB headset mic plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded "robotic". When plugged into the USB 2.0 port under EHCI on the same laptop, the audio sounded fine. The device is: Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset The problem was tracked down to the Fresco Logic xHCI host controller not correctly reporting short transfers on isochronous IN endpoints. The driver would submit a 96 byte transfer, the device would only send 88 or 90 bytes, and the xHCI host would report the transfer had a "successful" completion code, with an untransferred buffer length of 8 or 6 bytes. The successful completion code and non-zero untransferred length is a contradiction. The xHCI host is supposed to only mark a transfer as successful if all the bytes are transferred. Otherwise, the transfer should be marked with a short packet completion code. Without the EHCI bus trace, we wouldn't know whether the xHCI driver should trust the completion code or the untransferred length. With it, we know to trust the untransferred length. Add a new xHCI quirk for the Fresco Logic host controller. If a transfer is reported as successful, but the untransferred length is non-zero, print a warning. For the Fresco Logic host, change the completion code to COMP_SHORT_TX and process the transfer like a short transfer. This should be backported to stable kernels that contain the commit f5182b41 "xhci: Disable MSI for some Fresco Logic hosts." That commit was marked for stable kernels as old as 2.6.36. Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by: NSergio Correia <lists@uece.net> Tested-by: NSergio Correia <lists@uece.net> Cc: stable@vger.kernel.org Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
-
由 Jeffrin Jose 提交于
Fixed keyword related space issues found by checkpatch.pl tool in drivers/usb/storage/usb.c Signed-off-by: NJeffrin Jose <ahiliation@yahoo.co.in> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jeffrin Jose 提交于
Fixed several trailing white spaces issues found by checkpatch.pl tool in drivers/usb/storage/usb.c Signed-off-by: NJeffrin Jose <ahiliation@yahoo.co.in> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Jeffrin Jose 提交于
Fixed C99 comment issue in drivers/usb/storage/usb.c found using checkpatch.pl tool. Signed-off-by: NJeffrin Jose <ahiliation@yahoo.co.in> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 16 5月, 2012 22 次提交
-
-
由 Greg Kroah-Hartman 提交于
This reverts commit 6971113e. As Alan pointed out, this really isn't needed as it doesn't handle this properly. Ideally this should be handled by the usb-serial core one day. So revert it. Reported-by: NAlan Stern <stern@rowland.harvard.edu> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Johan Hovold <jhovold@gmail.com> Cc: Anton Samokhvalov <pg83@yandex.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
If the usb-serial driver doesn't have a reset_resume callback, then we need to tell the USB core that it doesn't, and it needs to rebind the device. Thanks to Alan for pointing out my mistake, and providing the fix. Reported-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
I hooked up the wrong callback in my previous patch, this should fix it. Reported-by: NAlan Stern <stern@rowland.harvard.edu> Cc: Johan Hovold <jhovold@gmail.com> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Andrzej Pietrasiewicz 提交于
Add FunctionFS support. It allows certain USB functions to be provided from userspace, e.g. MTP, PTP, adb. The functions provided by the gadget itself are enumerated in /sys/class/ccg0/functions. The functions which can be supplied from userspace must be enumerated in /sys/class/ccg0/f_fs/user_functions. No other userspace functions can be used than specified in the above mentioned file, but just specifying them there is not enough to activate them. The userspace functions in order to be activated need also be enumerated in /sys/class/ccg0/functions. An example sequence of operations can be as follows: $ echo 0 > /sys/class/ccg_usb/ccg0/enable $ echo -n 0x2d01 > /sys/module/g_ccg/parameters/idProduct $ echo -n MyDevice > /sys/module/g_ccg/parameters/iSerialNumber $ echo -n 0x1d6b > /sys/module/g_ccg/parameters/idVendor $ echo -n Manufacturer > /sys/module/g_ccg/parameters/iManufacturer $ echo -n Product > /sys/module/g_ccg/parameters/iProduct $ echo -n bcdDevice > /sys/module/g_ccg/parameters/bcdDevice $ echo adb,mtp,ptp > /sys/class/ccg_usb/ccg0/f_fs/user_functions $ echo mass_storage,ptp > /sys/class/ccg_usb/ccg0/functions $ echo /file.img > /sys/class/ccg_usb/ccg0/f_mass_storage/lun/file $ mkdir -p /dev/usbgadget/ptp $ mount -t functionfs ptp /dev/usbgadget/ptp $ ./ptp & $ echo 1 > /sys/class/ccg_usb/ccg0/enable The above example declares that adb, mtp and ptp functions can be supplied from userspace through FunctionFS. But of them all only ptp is actually activated, together with mass_storage, the latter being implemented in the gadget itself (in kernel, not in userspace). The list of functions can be modified at runtime while the gadget is not enabled, that is, after $ echo 0 > /sys/class/ccg_usb/ccg0/enable The FunctionFS function is implicitly handled by the gadget, that is, if a userspace function name is provided in /sys/class/ccg_usb/ccg0/functions, then the FunctionFS function is activated. Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Acked-by: NMichal Nazarewicz <mina86@mina86.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Mike Lockwood 提交于
The Configurable Gadget driver is a composite driver that allows userspace to change at runtime the list of functions enabled in its configuration and to configure these functions. It supports multiple functions: acm, rndis, and mass storage. It is usually controlled by a daemon that changes the configuration based on user settings. For example, rndis is enabled when the user enables sharing the phone data connection. As an example on how to use it, the following shell commands will make the gadget disconnect from the host and make it be re-enumerated as a composite with 1 rndis and 2 acm interfaces, and a different product id: echo 0 > /sys/class/ccg_usb/ccg0/enable echo rndis,acm > /sys/class/ccg_usb/ccg0/functions echo 2 > /sys/class/ccg_usb/ccg0/f_acm/instances echo -n 0x2d01 > /sys/module/g_ccg/parameters/idProduct echo 1 > /sys/class/ccg_usb/ccg0/enable The driver requires a gadget controller that supports software control of the D+ pullup and the controller driver must support disabling the pullup during composite_bind. Signed-off-by: NMike Lockwood <lockwood@android.com> Signed-off-by: NBenoit Goby <benoit@android.com> [import from android.c, implement review comments, remove adb,mtp,ptp,accessory] Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Bjørn Mork 提交于
Make some noise during probe to make sure the users are aware of the intended purpose of this driver. Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Nicolas Ferre 提交于
The patch 5a6506f0 (Update at91_udc to use usb_endpoint_descriptor inside the struct usb_ep) removes the desc field of struct at91_ep. This convertion had not been completed which leads to a compilation error. Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Sasha Levin 提交于
Commit da0af6e7 ("usb: Bind devices to ACPI devices when possible") really tries to force-bind devices even when impossible, unlike what it says in the subject. CONFIG_ACPI is not an indication that ACPI tables are actually present, nor is an indication that any USB relevant information is present in them. There is no reason to fail the creation of a USB bus if it can't bind it to ACPI device during initialization. On systems with CONFIG_ACPI set but without ACPI tables it would cause a boot panic. Signed-off-by: NSasha Levin <levinsasha928@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the symbolserial.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Rusty Russell <rusty@rustcorp.com.au> CC: Johan Hovold <jhovold@gmail.com> CC: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> CC: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the spcp8x5.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Rusty Russell <rusty@rustcorp.com.au> CC: Alan Stern <stern@rowland.harvard.edu> CC: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the qcserial.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Thomas Tuttle <ttuttle@chromium.org> CC: Alan Stern <stern@rowland.harvard.edu> CC: Paul Gortmaker <paul.gortmaker@windriver.com> CC: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the navman.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Rusty Russell <rusty@rustcorp.com.au> CC: Alan Stern <stern@rowland.harvard.edu> CC: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the ir-usb.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Rusty Russell <rusty@rustcorp.com.au> CC: Johan Hovold <jhovold@gmail.com> CC: Alan Stern <stern@rowland.harvard.edu> CC: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the ipaq.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Rusty Russell <rusty@rustcorp.com.au> CC: Johan Hovold <jhovold@gmail.com> CC: Alan Stern <stern@rowland.harvard.edu> CC: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the generic.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the f81232.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the belkin_sa.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: William Greathouse <wgreathouse@smva.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the ark3116.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Rusty Russell <rusty@rustcorp.com.au> CC: Alan Stern <stern@rowland.harvard.edu> CC: Mauro Carvalho Chehab <mchehab@redhat.com> CC: Bart Hartgers <bart.hartgers@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
dbg() is a usb-serial specific macro. This patch converts the aircable.c driver to use dev_dbg() instead to tie into the dynamic debug infrastructure. CC: Paul Gortmaker <paul.gortmaker@windriver.com> CC: Rusty Russell <rusty@rustcorp.com.au> CC: Alan Stern <stern@rowland.harvard.edu> CC: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
A few patches ago, I removed the reset_resume callback in this driver. Now that the usb-serial core supports reset_resume, put this driver callback back as well, so it should work identically to how it was originally. Now if this function really is doing what it should be doing, well, that's a different story, but we are at least doing the identical thing that we were before... Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Johan Hovold <jhovold@gmail.com> Cc: Anton Samokhvalov <pg83@yandex.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
A few patches ago, I removed the reset_resume callback, changing it to resume instead. Now that the usb-serial core supports reset_resume, put this driver callback back as well, so it should work identically to how it was originally. Now if this function really is doing what it should be doing, well, that's a different story, but we are at least doing the identical thing that we were before... Cc: Johan Hovold <jhovold@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
The callback is now hooked up for any USB to serial driver that wants it. We only register the callback if any of the usb-serial structures want it, this keeps the USB core happy. Thanks to Alan Stern for the ideas on how to do this. Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 5月, 2012 5 次提交
-
-
由 Richard Zhao 提交于
It's 0 for host only device. Signed-off-by: NRichard Zhao <richard.zhao@freescale.com> Cc: Marek Vasut <marex@denx.de> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Marek Vasut 提交于
Use usb_put_hcd() call instead of usb_remove_hcd() as that's the appropriate call to drop hcd which failed registration. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Marek Vasut 提交于
The CI13xxx usb host needs the root TT support to work properly. Allow selecting this for the CI13xxx too. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Felipe Balbi <balbi@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch (as1556) works around a bug in the Philips ISP1562 EHCI controller. Although the controller claims to support frame-list lengths smaller than the default of 1024 for its periodic schedule, in fact smaller values don't work. A new quirk flag is added to indicate when the bug is present, and if it is then the schedule size is left at the default value. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Alan Stern 提交于
This patch (as1555) improves the code ehci-hcd uses while checking the periodic schedule for isochronous transfers to full-speed devices. In addition to making sure that a new transfer does not violate the restrictions on the high-speed schedule, it also has to check the restrictions on the full-speed part of the bus, i.e., the part beyond the Transaction Translator (TT). It does this by calling tt_available() (or tt_no_collision() if CONFIG_USB_EHCI_TT_NEWSCHED isn't enabled). However it calls that routine on each pass through a loop over the frames being modified, which is an unnecessary expense because tt_available() (or tt_no_collision) already does its own loop over frames. It is sufficient to do the check just once, before starting the loop. In addition, the function calls incorrectly converted the transfer's period from microframes to frames by doing a left shift instead of a right shift. The patch fixes this while moving the calls. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-