linux-toradex.git/drivers/usb, branch v2.6.32.41 Linux kernel for Apalis and Colibri modules usb: musb: core: set has_tt flag 2011-05-09T22:55:41+00:00 Felipe Balbi balbi@ti.com 2011-02-24T08:36:53+00:00 49abf47d18ef1e3c67f3a29cd9eda03f48818652 commit ec95d35a6bd0047f05fe8a21e6c52f8bb418da55 upstream. MUSB is a non-standard host implementation which can handle all speeds with the same core. We need to set has_tt flag after commit d199c96d41d80a567493e12b8e96ea056a1350c1 (USB: prevent buggy hubs from crashing the USB stack) in order for MUSB HCD to continue working. Signed-off-by: Felipe Balbi <balbi@ti.com> Cc: Alan Stern <stern@rowland.harvard.edu> Tested-by: Michael Jones <michael.jones@matrix-vision.de> Tested-by: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit ec95d35a6bd0047f05fe8a21e6c52f8bb418da55 upstream.

MUSB is a non-standard host implementation which
can handle all speeds with the same core. We need
to set has_tt flag after commit
d199c96d41d80a567493e12b8e96ea056a1350c1 (USB: prevent
buggy hubs from crashing the USB stack) in order for
MUSB HCD to continue working.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Michael Jones <michael.jones@matrix-vision.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: teach "devices" file about Wireless and SuperSpeed USB 2011-05-09T22:55:10+00:00 Alan Stern stern@rowland.harvard.edu 2010-09-13T18:43:25+00:00 a89861f3694d7e5bcd3d1d2ab2abe040ca044e0a commit 834e2312e7a384877a876b0d34dffc3046c96bcb upstream. USB: teach "devices" file about Wireless and SuperSpeed USB The /sys/kernel/debug/usb/devices file doesn't know about Wireless or SuperSpeed USB. This patch (as1416b) teaches it, and updates the Documentation/usb/proc_sub_info.txt file accordingly. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Vrabel <david.vrabel@csr.com> CC: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> [Julien Blache: The original commit also added the correct speed for USB_SPEED_WIRELESS, I removed it as it's not supported in 2.6.32.] Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 834e2312e7a384877a876b0d34dffc3046c96bcb upstream.

USB: teach "devices" file about Wireless and SuperSpeed USB

The /sys/kernel/debug/usb/devices file doesn't know about Wireless or
SuperSpeed USB.  This patch (as1416b) teaches it, and updates the
Documentation/usb/proc_sub_info.txt file accordingly.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: David Vrabel <david.vrabel@csr.com>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[Julien Blache: The original commit also added the correct speed for
 USB_SPEED_WIRELESS, I removed it as it's not supported in 2.6.32.]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: don't enable remote wakeup by default 2011-05-09T22:55:10+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-02T17:21:33+00:00 5e35287b2bfc877558acc9ad67aca7ace01021e8 commit 7aba8d014341341590ecb64050b7a026642a62eb upstream. This patch (as1364) avoids enabling remote wakeup by default on all non-root-hub USB devices. Individual drivers or userspace will have to enable it wherever it is needed, such as for keyboards or network interfaces. Note: This affects only system sleep, not autosuspend. External hubs will continue to relay wakeup requests received from downstream through their upstream port, even when remote wakeup is not enabled for the hub itself. Disabling remote wakeup on a hub merely prevents it from generating wakeup requests in response to connect, disconnect, and overcurrent events. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 7aba8d014341341590ecb64050b7a026642a62eb upstream.

This patch (as1364) avoids enabling remote wakeup by default on all
non-root-hub USB devices.  Individual drivers or userspace will have
to enable it wherever it is needed, such as for keyboards or network
interfaces.  Note: This affects only system sleep, not autosuspend.

External hubs will continue to relay wakeup requests received from
downstream through their upstream port, even when remote wakeup is not
enabled for the hub itself.  Disabling remote wakeup on a hub merely
prevents it from generating wakeup requests in response to connect,
disconnect, and overcurrent events.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: retain USB device power/wakeup setting across reconfiguration 2011-05-09T22:55:10+00:00 Dan Streetman ddstreet@ieee.org 2010-01-06T14:56:53+00:00 a30ded70e8160aa6dc8d0c1d4c9dacc47a38fee3 commit 16985408b5c48585762ec3b9b7bae1dec4ad7437 upstream. Currently a non-root-hub USB device's wakeup settings are initialized when the device is set to a configured state using device_init_wakeup(), but this is not correct as wakeup is split into "capable" (can_wakeup) and "enabled" (should_wakeup). The settings should be initialized instead in the device initialization (usb_new_device) with the "capable" setting disabled and the "enabled" setting enabled. The "capable" setting should be set based on the device being configured or unconfigured, and "enabled" setting set based on the sysfs power/wakeup control. This patch retains the sysfs power/wakeup setting of a non-root-hub USB device over a USB device re-configuration, which can happen (for example) after a suspend/resume cycle. Signed-off-by: Dan Streetman <ddstreet@ieee.org> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> [bwh: Adjust context for 2.6.32] Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 16985408b5c48585762ec3b9b7bae1dec4ad7437 upstream.

Currently a non-root-hub USB device's wakeup settings are initialized when the
device is set to a configured state using device_init_wakeup(), but this is not
correct as wakeup is split into "capable" (can_wakeup) and "enabled"
(should_wakeup).  The settings should be initialized instead in the device
initialization (usb_new_device) with the "capable" setting disabled and the
"enabled" setting enabled.  The "capable" setting should be set based on the
device being configured or unconfigured, and "enabled" setting set based on
the sysfs power/wakeup control.

This patch retains the sysfs power/wakeup setting of a non-root-hub USB device
over a USB device re-configuration, which can happen (for example) after a
suspend/resume cycle.

Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[bwh: Adjust context for 2.6.32]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci - fix math in xhci_get_endpoint_interval() 2011-04-22T15:44:29+00:00 Dmitry Torokhov dtor@vmware.com 2011-03-24T05:41:23+00:00 5d7a20b586ff6ce07faa60c54947477248d34848 commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream. When parsing exponent-expressed intervals we subtract 1 from the value and then expect it to match with original + 1, which is highly unlikely, and we end with frequent spew: usb 3-4: ep 0x83 - rounding interval to 512 microframes Also, parsing interval for fullspeed isochronous endpoints was incorrect - according to USB spec they use exponent-based intervals (but xHCI spec claims frame-based intervals). I trust USB spec more, especially since USB core agrees with it. This should be queued for stable kernels back to 2.6.31. Reviewed-by: Micah Elizabeth Scott <micah@vmware.com> Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a upstream.

When parsing exponent-expressed intervals we subtract 1 from the
value and then expect it to match with original + 1, which is
highly unlikely, and we end with frequent spew:

	usb 3-4: ep 0x83 - rounding interval to 512 microframes

Also, parsing interval for fullspeed isochronous endpoints was
incorrect - according to USB spec they use exponent-based
intervals (but xHCI spec claims frame-based intervals). I trust
USB spec more, especially since USB core agrees with it.

This should be queued for stable kernels back to 2.6.31.

Reviewed-by: Micah Elizabeth Scott <micah@vmware.com>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci - fix unsafe macro definitions 2011-04-22T15:44:29+00:00 Dmitry Torokhov dtor@vmware.com 2011-03-20T09:15:17+00:00 53d5fa19a47b286d94264b630e24709e80a33cd5 commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream. Macro arguments used in expressions need to be enclosed in parenthesis to avoid unpleasant surprises. This should be queued for kernels back to 2.6.31 Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 5a6c2f3ff039154872ce597952f8b8900ea0d732 upstream.

Macro arguments used in expressions need to be enclosed in parenthesis
to avoid unpleasant surprises.

This should be queued for kernels back to 2.6.31

Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix formatting of SuperSpeed endpoints in /proc/bus/usb/devices 2011-04-22T15:44:28+00:00 Dmitry Torokhov dtor@vmware.com 2011-03-19T04:29:01+00:00 b90adfeb126662df944e7fdfcd732ab10df6454c commit 2868a2b1ba8f9c7f6c4170519ebb6c62934df70e upstream. Isochronous and interrupt SuperSpeed endpoints use the same mechanisms for decoding bInterval values as HighSpeed ones so adjust the code accordingly. Also bandwidth reservation for SuperSpeed matches highspeed, not low/full speed. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 2868a2b1ba8f9c7f6c4170519ebb6c62934df70e upstream.

Isochronous and interrupt SuperSpeed endpoints use the same mechanisms
for decoding bInterval values as HighSpeed ones so adjust the code
accordingly.

Also bandwidth reservation for SuperSpeed matches highspeed, not
low/full speed.

Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI: unlink unused QHs when the controller is stopped 2011-04-22T15:44:27+00:00 Alan Stern stern@rowland.harvard.edu 2011-04-05T17:36:15+00:00 a572af6883a6af871d9f20894f6b51a2749f3c22 commit 94ae4976e253757e9b03a44d27d41b20f1829d80 upstream. This patch (as1458) fixes a problem affecting ultra-reliable systems: When hardware failover of an EHCI controller occurs, the data structures do not get released correctly. This is because the routine responsible for removing unused QHs from the async schedule assumes the controller is running properly (the frame counter is used in determining how long the QH has been idle) -- but when a failover causes the controller to be electronically disconnected from the PCI bus, obviously it stops running. The solution is simple: Allow scan_async() to remove a QH from the async schedule if it has been idle for long enough _or_ if the controller is stopped. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-Tested-by: Dan Duval <dan.duval@stratus.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 94ae4976e253757e9b03a44d27d41b20f1829d80 upstream.

This patch (as1458) fixes a problem affecting ultra-reliable systems:
When hardware failover of an EHCI controller occurs, the data
structures do not get released correctly.  This is because the routine
responsible for removing unused QHs from the async schedule assumes
the controller is running properly (the frame counter is used in
determining how long the QH has been idle) -- but when a failover
causes the controller to be electronically disconnected from the PCI
bus, obviously it stops running.

The solution is simple: Allow scan_async() to remove a QH from the
async schedule if it has been idle for long enough _or_ if the
controller is stopped.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-Tested-by: Dan Duval <dan.duval@stratus.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: option: Added support for Samsung GT-B3730/GT-B3710 LTE USB modem. 2011-04-22T15:44:24+00:00 Marius B. Kotsbak marius@kotsbak.com 2011-03-21T23:01:53+00:00 3aed738e4f41feb2e18ce448bc53751beab49128 commit 80f9df3e0093ad9f1eeefd2ff7fd27daaa518d25 upstream. Bind only modem AT command endpoint to option. Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 80f9df3e0093ad9f1eeefd2ff7fd27daaa518d25 upstream.

Bind only modem AT command endpoint to option.

Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: option: Add new ONDA vendor id and product id for ONDA MT825UP 2011-04-22T15:44:23+00:00 Enrico Mioso mrkiko.rs@gmail.com 2010-09-17T08:54:23+00:00 3cd02e97347a65765dc8e8031b90bc0cd3cfad31 commit c6991b6fd2b4201174dc4620d0c8c4f5ff27b36f upstream. This patch, adds to the option driver the Onda Communication (http://www.ondacommunication.com) vendor id, and the MT825UP modem device id. Note that many variants of this same device are being release here in Italy (at least one or two per telephony operator). These devices are perfectly equivalent except for some predefined settings (which can be changed of course). It should be noted that most ONDA devices are allready supported (they used other vendor's ids in the past). The patch seems working fine here, and the rest of the driver seems uninfluenced. Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit c6991b6fd2b4201174dc4620d0c8c4f5ff27b36f upstream.

This patch, adds to the option driver the Onda Communication
(http://www.ondacommunication.com) vendor id, and the MT825UP modem
device id.

Note that many variants of this same device are being release here in
Italy (at least one or two per telephony operator).

These devices are perfectly equivalent except for some predefined
settings (which can be changed of course).

It should be noted that most ONDA devices are allready supported (they
used other vendor's ids in the past). The patch seems working fine here,
and the rest of the driver seems uninfluenced.

Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>