linux-toradex.git/drivers/usb, branch v2.6.32.15 Linux kernel for Apalis and Colibri modules USB: xhci: properly set endpoint context fields for periodic eps. 2010-05-12T21:57:03+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-04-16T15:07:27+00:00 2e80b07dcdbe27eda40447ad48e26662beea7b4c commit 9238f25d5d32a435277eb234ec82bacdd5daed41 upstream. For periodic endpoints, we must let the xHCI hardware know the maximum payload an endpoint can transfer in one service interval. The xHCI specification refers to this as the Maximum Endpoint Service Interval Time Payload (Max ESIT Payload). This is used by the hardware for bandwidth management and scheduling of packets. For SuperSpeed endpoints, the maximum is calculated by multiplying the max packet size by the number of bursts and the number of opportunities to transfer within a service interval (the Mult field of the SuperSpeed Endpoint companion descriptor). Devices advertise this in the wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor. For high speed devices, this is taken by multiplying the max packet size by the "number of additional transaction opportunities per microframe" (the high bits of the wMaxPacketSize field in the endpoint descriptor). For FS/LS devices, this is just the max packet size. The other thing we must set in the endpoint context is the Average TRB Length. This is supposed to be the average of the total bytes in the transfer descriptor (TD), divided by the number of transfer request blocks (TRBs) it takes to describe the TD. This gives the host controller an indication of whether the driver will be enqueuing a scatter gather list with many entries comprised of small buffers, or one contiguous buffer. It also takes into account the number of extra TRBs you need for every TD. This includes No-op TRBs and Link TRBs used to link ring segments together. Some drivers may choose to chain an Event Data TRB on the end of every TD, thus increasing the average number of TRBs per TD. The Linux xHCI driver does not use Event Data TRBs. In theory, if there was an API to allow drivers to state what their bandwidth requirements are, we could set this field accurately. For now, we set it to the same number as the Max ESIT payload. The Average TRB Length should also be set for bulk and control endpoints, but I have no idea how to guess what it should be. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 9238f25d5d32a435277eb234ec82bacdd5daed41 upstream.

For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval.  The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload).  This is used by the hardware for bandwidth
management and scheduling of packets.

For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor).  Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.

For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).

For FS/LS devices, this is just the max packet size.

The other thing we must set in the endpoint context is the Average TRB
Length.  This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD.  This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.

It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together.  Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD.  The Linux
xHCI driver does not use Event Data TRBs.

In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately.  For now,
we set it to the same number as the Max ESIT payload.

The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: properly set the "Mult" field of the endpoint context. 2010-05-12T21:57:03+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-04-16T15:07:04+00:00 0a0da543426241627580bda5fccb5ddf444a1aba commit 1cf62246c0e394021e494e0a8f1013e80db1a1a9 upstream. A SuperSpeed interrupt or isochronous endpoint can define the number of "burst transactions" it can handle in a service interval. This is indicated by the "Mult" bits in the bmAttributes of the SuperSpeed Endpoint Companion Descriptor. For example, if it has a max packet size of 1024, a max burst of 11, and a mult of 3, the host may send 33 1024-byte packets in one service interval. We must tell the xHCI host controller the number of multiple service opportunities (mults) the device can handle when the endpoint is installed. We do that by setting the Mult field of the Endpoint Context before a configure endpoint command is sent down. The Mult field is invalid for control or bulk SuperSpeed endpoints. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 1cf62246c0e394021e494e0a8f1013e80db1a1a9 upstream.

A SuperSpeed interrupt or isochronous endpoint can define the number of
"burst transactions" it can handle in a service interval.  This is
indicated by the "Mult" bits in the bmAttributes of the SuperSpeed
Endpoint Companion Descriptor.  For example, if it has a max packet size
of 1024, a max burst of 11, and a mult of 3, the host may send 33
1024-byte packets in one service interval.

We must tell the xHCI host controller the number of multiple service
opportunities (mults) the device can handle when the endpoint is
installed.  We do that by setting the Mult field of the Endpoint Context
before a configure endpoint command is sent down.  The Mult field is
invalid for control or bulk SuperSpeed endpoints.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: OHCI: don't look at the root hub to get the number of ports 2010-05-12T21:57:02+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-20T14:37:57+00:00 dd13b9f4a90b5dcefb7ef36393a55c96f3f10a76 commit fcf7d2141f4a363a4a8454c4a0f26bb69e766c5f upstream. This patch (as1371) fixes a small bug in ohci-hcd. The HCD already knows how many ports the controller has; there's no need to go looking at the root hub's usb_device structure to find out. Especially since the root hub's maxchild value is set correctly only while the root hub is bound to the hub driver. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit fcf7d2141f4a363a4a8454c4a0f26bb69e766c5f upstream.

This patch (as1371) fixes a small bug in ohci-hcd.  The HCD already
knows how many ports the controller has; there's no need to go looking
at the root hub's usb_device structure to find out.  Especially since
the root hub's maxchild value is set correctly only while the root hub
is bound to the hub driver.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: don't choose configs with no interfaces 2010-05-12T21:57:02+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-20T14:40:59+00:00 0f6f37f1a93d1936d18e99739062f783118c9f98 commit 62f9cfa3ece58268b3e92ca59c23b175f86205aa upstream. This patch (as1372) fixes a bug in the routine that chooses the default configuration to install when a new USB device is detected. The algorithm is supposed to look for a config whose first interface is for a non-vendor-specific class. But the way it's currently written, it will also accept a config with no interfaces at all, which is not very useful. (Believe it or not, such things do exist.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Andrew Victor <avictor.za@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 62f9cfa3ece58268b3e92ca59c23b175f86205aa upstream.

This patch (as1372) fixes a bug in the routine that chooses the
default configuration to install when a new USB device is detected.
The algorithm is supposed to look for a config whose first interface
is for a non-vendor-specific class.  But the way it's currently
written, it will also accept a config with no interfaces at all, which
is not very useful.  (Believe it or not, such things do exist.)

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andrew Victor <avictor.za@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix testing the wrong variable in fs_create_by_name() 2010-05-12T21:57:02+00:00 Dan Carpenter error27@gmail.com 2010-04-22T10:00:52+00:00 b7cbd217d5a3197fa38f88a89bb75fa6bf7121b4 commit fa7fe7af146a7b613e36a311eefbbfb5555325d1 upstream. There is a typo here. We should be testing "*dentry" which was just assigned instead of "dentry". This could result in dereferencing an ERR_PTR inside either usbfs_mkdir() or usbfs_create(). Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit fa7fe7af146a7b613e36a311eefbbfb5555325d1 upstream.

There is a typo here.  We should be testing "*dentry" which was just
assigned instead of "dentry".  This could result in dereferencing an
ERR_PTR inside either usbfs_mkdir() or usbfs_create().

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: Add id for HP ev2210 a.k.a Sierra MC5725 miniPCI-e Cell Modem. 2010-05-12T21:57:02+00:00 William Lightning kassah@gmail.com 2010-03-26T17:51:20+00:00 a559bbbda22d8905fe71cbcb9f1ea11b8a9668a7 commit cfbaa39347b34837f26e01fe8f4f8dbbae60b520 upstream. Signed-off-by: William Lightning <kassah@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit cfbaa39347b34837f26e01fe8f4f8dbbae60b520 upstream.

Signed-off-by: William Lightning <kassah@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: fix remote wakeup settings during system sleep 2010-05-12T21:57:01+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-30T16:09:23+00:00 2fb9d8cdf50d3d2353da727c8faf4fa1ea0eb2b6 This is a backport of commit 5f677f1d45b2bf08085bbba7394392dfa586fa8e. Some of the functionality had to be removed, but it should still fix the webcam problem. This patch (as1363b) changes the way USB remote wakeup is handled during system sleeps. It won't be enabled unless an interface driver specifically needs it. Also, it won't be enabled during the FREEZE or QUIESCE phases of hibernation, when the system doesn't respond to wakeup events anyway. This will fix problems people have reported with certain USB webcams that generate wakeup requests when they shouldn't, and as a result cause system suspends to fail. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/515109 Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This is a backport of commit 5f677f1d45b2bf08085bbba7394392dfa586fa8e.
Some of the functionality had to be removed, but it should still fix
the webcam problem.

This patch (as1363b) changes the way USB remote wakeup is handled
during system sleeps.  It won't be enabled unless an interface driver
specifically needs it.  Also, it won't be enabled during the FREEZE or
QUIESCE phases of hibernation, when the system doesn't respond to
wakeup events anyway.

This will fix problems people have reported with certain USB webcams
that generate wakeup requests when they shouldn't, and as a result
cause system suspends to fail.  See

	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/515109


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI: defer reclamation of siTDs 2010-05-12T21:56:59+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-08T20:56:37+00:00 9ab04f8dc2ec32b1065ab9dfcca3c92456fa77e0 commit 0e5f231bc16ff9910882fa5b9d64d80e7691cfab upstream. This patch (as1369) fixes a problem in ehci-hcd. Some controllers occasionally run into trouble when the driver reclaims siTDs too quickly. This can happen while streaming audio; it causes the controller to crash. The patch changes siTD reclamation to work the same way as iTD reclamation: Completed siTDs are stored on a list and not reused until at least one frame has passed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Nate Case <ncase@xes-inc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 0e5f231bc16ff9910882fa5b9d64d80e7691cfab upstream.

This patch (as1369) fixes a problem in ehci-hcd.  Some controllers
occasionally run into trouble when the driver reclaims siTDs too
quickly.  This can happen while streaming audio; it causes the
controller to crash.

The patch changes siTD reclamation to work the same way as iTD
reclamation: Completed siTDs are stored on a list and not reused until
at least one frame has passed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Nate Case <ncase@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: cdc-acm: Fix stupid NULL pointer in resume() 2010-04-26T14:41:33+00:00 Oliver Neukum oliver@neukum.org 2010-03-02T23:37:56+00:00 f48673e5235732da41d9cd57365a5a3d7b71a32e commit f0730924e9e32bb8935c60040a26d94179355088 upstream. Stupid logic bug passing a just nulled pointer Signed-off-by: Oliver Neukum <neukum@b1-systems.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit f0730924e9e32bb8935c60040a26d94179355088 upstream.

Stupid logic bug passing a just nulled pointer

Signed-off-by: Oliver Neukum <neukum@b1-systems.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: cdc-acm: Update to new autopm API 2010-04-26T14:41:33+00:00 Oliver Neukum oliver@neukum.org 2009-12-16T16:05:57+00:00 9db126bccc557e0587740094e3c2c7d3451c5de9 commit 97d35f95552c9a0ee4777a7f04431a9fd1260478 upstream. Update cdc-acm to the async methods eliminating the workqueue [This fixes a reported lockup for the cdc-acm driver - gregkh] Signed-off-by: Oliver Neukum <oliver@neukum.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 97d35f95552c9a0ee4777a7f04431a9fd1260478 upstream.

Update cdc-acm to the async methods eliminating the workqueue

[This fixes a reported lockup for the cdc-acm driver - gregkh]

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>