<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/usb/core, branch v3.2.19</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>USB: Remove races in devio.c</title>
<updated>2012-05-30T23:43:45+00:00</updated>
<author>
<name>Huajun Li</name>
<email>huajun.li.lee@gmail.com</email>
</author>
<published>2012-05-18T12:12:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8903f762151994729c79eae3b5afc9fc399be905'/>
<id>8903f762151994729c79eae3b5afc9fc399be905</id>
<content type='text'>
commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream.

There exist races in devio.c, below is one case,
and there are similar races in destroy_async()
and proc_unlinkurb().  Remove these races.

 cancel_bulk_urbs()        async_completed()
-------------------                -----------------------
 spin_unlock(&amp;ps-&gt;lock);

                           list_move_tail(&amp;as-&gt;asynclist,
		                    &amp;ps-&gt;async_completed);

                           wake_up(&amp;ps-&gt;wait);

                           Lead to free_async() be triggered,
                           then urb and 'as' will be freed.

 usb_unlink_urb(as-&gt;urb);
 ===&gt; refer to the freed 'as'

Signed-off-by: Huajun Li &lt;huajun.li.lee@gmail.com&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: Oncaphillis &lt;oncaphillis@snafu.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4e09dcf20f7b5358615514c2ec8584b248ab8874 upstream.

There exist races in devio.c, below is one case,
and there are similar races in destroy_async()
and proc_unlinkurb().  Remove these races.

 cancel_bulk_urbs()        async_completed()
-------------------                -----------------------
 spin_unlock(&amp;ps-&gt;lock);

                           list_move_tail(&amp;as-&gt;asynclist,
		                    &amp;ps-&gt;async_completed);

                           wake_up(&amp;ps-&gt;wait);

                           Lead to free_async() be triggered,
                           then urb and 'as' will be freed.

 usb_unlink_urb(as-&gt;urb);
 ===&gt; refer to the freed 'as'

Signed-off-by: Huajun Li &lt;huajun.li.lee@gmail.com&gt;
Cc: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Cc: Oncaphillis &lt;oncaphillis@snafu.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usbcore: enable USB2 LPM if port suspend fails</title>
<updated>2012-05-30T23:43:43+00:00</updated>
<author>
<name>Andiry Xu</name>
<email>andiry.xu@gmail.com</email>
</author>
<published>2012-05-04T16:50:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=adc4185584c4fd1c057cafe152fc69994a9786e6'/>
<id>adc4185584c4fd1c057cafe152fc69994a9786e6</id>
<content type='text'>
commit c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream.

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 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM".

Signed-off-by: Andiry Xu &lt;andiry.xu@gmail.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c3e751e4f4754793bb52bd5ae30e9cc027edbb12 upstream.

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 65580b4321eb36f16ae8b5987bfa1bb948fc5112 "xHCI: set USB2
hardware LPM".

Signed-off-by: Andiry Xu &lt;andiry.xu@gmail.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es</title>
<updated>2012-05-30T23:43:33+00:00</updated>
<author>
<name>Steffen Müller</name>
<email>steffen.mueller@radio-frei.de</email>
</author>
<published>2012-04-30T11:05:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0e3d4a41d1df3fc7c181fe02fd23caf36791265e'/>
<id>0e3d4a41d1df3fc7c181fe02fd23caf36791265e</id>
<content type='text'>
commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream.

Tested-by: Steffen Müller &lt;steffen.mueller@radio-frei.de&gt;
Signed-off-by: Steffen Müller &lt;steffen.mueller@radio-frei.de&gt;
Signed-off-by: Stefan Seyfried &lt;seife+kernel@b1-systems.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 166cb70e97bd83d7ae9bbec6ae59a178fd9bb823 upstream.

Tested-by: Steffen Müller &lt;steffen.mueller@radio-frei.de&gt;
Signed-off-by: Steffen Müller &lt;steffen.mueller@radio-frei.de&gt;
Signed-off-by: Stefan Seyfried &lt;seife+kernel@b1-systems.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: move usb_translate_errors to linux/usb.h</title>
<updated>2012-05-30T23:43:31+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2011-11-10T13:58:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9323f37754016b3fa76419d0e0ad9a56fcf0dd96'/>
<id>9323f37754016b3fa76419d0e0ad9a56fcf0dd96</id>
<content type='text'>
commit 2c4d6bf295ae10ffcd84f0df6cb642598eb66603 upstream.

Move usb_translate_errors from usb core to linux/usb.h as it is meant to
be accessed from drivers.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2c4d6bf295ae10ffcd84f0df6cb642598eb66603 upstream.

Move usb_translate_errors from usb core to linux/usb.h as it is meant to
be accessed from drivers.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: EHCI: fix crash during suspend on ASUS computers</title>
<updated>2012-05-11T12:14:42+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-04-24T18:07:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f845dfabaf943e9d1bd97c1c023ee5c58ba04352'/>
<id>f845dfabaf943e9d1bd97c1c023ee5c58ba04352</id>
<content type='text'>
commit 151b61284776be2d6f02d48c23c3625678960b97 upstream.

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: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Tested-by: Andrey Rahmatullin &lt;wrar@wrar.name&gt;
Tested-by: Oleksij Rempel (fishor) &lt;bug-track@fisher-privat.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 151b61284776be2d6f02d48c23c3625678960b97 upstream.

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: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Tested-by: Andrey Rahmatullin &lt;wrar@wrar.name&gt;
Tested-by: Oleksij Rempel (fishor) &lt;bug-track@fisher-privat.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: fix deadlock in bConfigurationValue attribute method</title>
<updated>2012-05-11T12:14:03+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-04-17T19:22:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=90114113b4dc19abc832f03f1c1b7b837ba00af0'/>
<id>90114113b4dc19abc832f03f1c1b7b837ba00af0</id>
<content type='text'>
commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream.

This patch (as154) fixes a self-deadlock that occurs when userspace
writes to the bConfigurationValue sysfs attribute for a hub with
children.  The task tries to lock the bandwidth_mutex at a time when
it already owns the lock:

	The attribute's method calls usb_set_configuration(),
	which calls usb_disable_device() with the bandwidth_mutex
	held.

	usb_disable_device() unregisters the existing interfaces,
	which causes the hub driver to be unbound.

	The hub_disconnect() routine calls hub_quiesce(), which
	calls usb_disconnect() for each of the hub's children.

	usb_disconnect() attempts to acquire the bandwidth_mutex
	around a call to usb_disable_device().

The solution is to make usb_disable_device() acquire the mutex for
itself instead of requiring the caller to hold it.  Then the mutex can
cover only the bandwidth deallocation operation and not the region
where the interfaces are unregistered.

This has the potential to change system behavior slightly when a
config change races with another config or altsetting change.  Some of
the bandwidth released from the old config might get claimed by the
other config or altsetting, make it impossible to restore the old
config in case of a failure.  But since we don't try to recover from
config-change failures anyway, this doesn't matter.

[This should be marked for stable kernels that contain the commit
fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when
usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream.

This patch (as154) fixes a self-deadlock that occurs when userspace
writes to the bConfigurationValue sysfs attribute for a hub with
children.  The task tries to lock the bandwidth_mutex at a time when
it already owns the lock:

	The attribute's method calls usb_set_configuration(),
	which calls usb_disable_device() with the bandwidth_mutex
	held.

	usb_disable_device() unregisters the existing interfaces,
	which causes the hub driver to be unbound.

	The hub_disconnect() routine calls hub_quiesce(), which
	calls usb_disconnect() for each of the hub's children.

	usb_disconnect() attempts to acquire the bandwidth_mutex
	around a call to usb_disable_device().

The solution is to make usb_disable_device() acquire the mutex for
itself instead of requiring the caller to hold it.  Then the mutex can
cover only the bandwidth deallocation operation and not the region
where the interfaces are unregistered.

This has the potential to change system behavior slightly when a
config change races with another config or altsetting change.  Some of
the bandwidth released from the old config might get claimed by the
other config or altsetting, make it impossible to restore the old
config in case of a failure.  But since we don't try to recover from
config-change failures anyway, this doesn't matter.

[This should be marked for stable kernels that contain the commit
fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when
usb_disable_device is called."
That commit was marked for stable kernels as old as 2.6.32.]

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: fix bug of device descriptor got from superspeed device</title>
<updated>2012-04-22T22:31:03+00:00</updated>
<author>
<name>Elric Fu</name>
<email>elricfu1@gmail.com</email>
</author>
<published>2012-03-26T13:16:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3277b4abfab889a877d0c30edf1209dff035a559'/>
<id>3277b4abfab889a877d0c30edf1209dff035a559</id>
<content type='text'>
commit d8aec3dbdfd02627e198e7956ab4aaeba2a349fa upstream.

When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.

The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09

But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40

The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.

This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.

This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore:
refine warm reset logic".

Signed-off-by: Elric Fu &lt;elricfu1@gmail.com&gt;
Acked-by: Andiry Xu &lt;Andiry.Xu@amd.com&gt;
Acked-by: Sergei Shtylyov &lt;sshtylyov@mvista.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d8aec3dbdfd02627e198e7956ab4aaeba2a349fa upstream.

When the Seagate Goflex USB3.0 device is attached to VIA xHCI
host, sometimes the device will downgrade mode to high speed.
By the USB analyzer, I found the device finished the link
training process and worked at superspeed mode. But the device
descriptor got from the device shows the device works at 2.1.
It is very strange and seems like the device controller of
Seagate Goflex has a little confusion.

The first 8 bytes of device descriptor should be:
12 01 00 03 00 00 00 09

But the first 8 bytes of wrong device descriptor are:
12 01 10 02 00 00 00 40

The wrong device descriptor caused the initialization of mass
storage failed. After a while, the device would be recognized
as a high speed device and works fine.

This patch will warm reset the device to fix the issue after
finding the bcdUSB field of device descriptor isn't 0x0300
but the speed mode of device is superspeed.

This patch should be backported to kernels as old as 3.2, or ones that
contain the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore:
refine warm reset logic".

Signed-off-by: Elric Fu &lt;elricfu1@gmail.com&gt;
Acked-by: Andiry Xu &lt;Andiry.Xu@amd.com&gt;
Acked-by: Sergei Shtylyov &lt;sshtylyov@mvista.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: don't ignore suspend errors for root hubs</title>
<updated>2012-04-22T22:31:03+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-03-28T19:56:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=933ec440ffb8b188ab415b67ce975058ef795dbe'/>
<id>933ec440ffb8b188ab415b67ce975058ef795dbe</id>
<content type='text'>
commit cd4376e23a59a2adf3084cb5f4a523e6d5fd4e49 upstream.

This patch (as1532) fixes a mistake in the USB suspend code.  When the
system is going to sleep, we should ignore errors in powering down USB
devices, because they don't really matter.  The devices will go to low
power anyway when the entire USB bus gets suspended (except for
SuperSpeed devices; maybe they will need special treatment later).

However we should not ignore errors in suspending root hubs,
especially if the error indicates that the suspend raced with a wakeup
request.  Doing so might leave the bus powered on while the system was
supposed to be asleep, or it might cause the suspend of the root hub's
parent controller device to fail, or it might cause a wakeup request
to be ignored.

The patch fixes the problem by ignoring errors only when the device in
question is not a root hub.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Chen Peter &lt;B29397@freescale.com&gt;
Tested-by: Chen Peter &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cd4376e23a59a2adf3084cb5f4a523e6d5fd4e49 upstream.

This patch (as1532) fixes a mistake in the USB suspend code.  When the
system is going to sleep, we should ignore errors in powering down USB
devices, because they don't really matter.  The devices will go to low
power anyway when the entire USB bus gets suspended (except for
SuperSpeed devices; maybe they will need special treatment later).

However we should not ignore errors in suspending root hubs,
especially if the error indicates that the suspend raced with a wakeup
request.  Doing so might leave the bus powered on while the system was
supposed to be asleep, or it might cause the suspend of the root hub's
parent controller device to fail, or it might cause a wakeup request
to be ignored.

The patch fixes the problem by ignoring errors only when the device in
question is not a root hub.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Chen Peter &lt;B29397@freescale.com&gt;
Tested-by: Chen Peter &lt;peter.chen@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: don't clear urb-&gt;dev in scatter-gather library</title>
<updated>2012-04-22T22:31:02+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-03-22T15:00:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5199257b1b2849e1e6bb73e323bd61e6beb8de45'/>
<id>5199257b1b2849e1e6bb73e323bd61e6beb8de45</id>
<content type='text'>
commit bcf398537630bf20b4dbe59ba855b69f404c93cf upstream.

This patch (as1517b) fixes an error in the USB scatter-gather library.
The library code uses urb-&gt;dev to determine whether or nor an URB is
currently active; the completion handler sets urb-&gt;dev to NULL.
However the core unlinking routines need to use urb-&gt;dev.  Since
unlinking always racing with completion, the completion handler must
not clear urb-&gt;dev -- it can lead to invalid memory accesses when a
transfer has to be cancelled.

This patch fixes the problem by getting rid of the lines that clear
urb-&gt;dev after urb has been submitted.  As a result we may end up
trying to unlink an URB that failed in submission or that has already
completed, so an extra check is added after each unlink to avoid
printing an error message when this happens.  The checks are updated
in both sg_complete() and sg_cancel(), and the second is updated to
match the first (currently it prints out unnecessary warning messages
if a device is unplugged while a transfer is in progress).

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-and-tested-by: Illia Zaitsev &lt;I.Zaitsev@adbglobal.com&gt;
CC: Ming Lei &lt;tom.leiming@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit bcf398537630bf20b4dbe59ba855b69f404c93cf upstream.

This patch (as1517b) fixes an error in the USB scatter-gather library.
The library code uses urb-&gt;dev to determine whether or nor an URB is
currently active; the completion handler sets urb-&gt;dev to NULL.
However the core unlinking routines need to use urb-&gt;dev.  Since
unlinking always racing with completion, the completion handler must
not clear urb-&gt;dev -- it can lead to invalid memory accesses when a
transfer has to be cancelled.

This patch fixes the problem by getting rid of the lines that clear
urb-&gt;dev after urb has been submitted.  As a result we may end up
trying to unlink an URB that failed in submission or that has already
completed, so an extra check is added after each unlink to avoid
printing an error message when this happens.  The checks are updated
in both sg_complete() and sg_cancel(), and the second is updated to
match the first (currently it prints out unnecessary warning messages
if a device is unplugged while a transfer is in progress).

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-and-tested-by: Illia Zaitsev &lt;I.Zaitsev@adbglobal.com&gt;
CC: Ming Lei &lt;tom.leiming@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: Set hub depth after USB3 hub reset</title>
<updated>2012-03-01T00:31:08+00:00</updated>
<author>
<name>Elric Fu</name>
<email>elricfu1@gmail.com</email>
</author>
<published>2012-02-18T05:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1a624979096199f383fc7785a509d1e38b608986'/>
<id>1a624979096199f383fc7785a509d1e38b608986</id>
<content type='text'>
commit a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c upstream.

The superspeed device attached to a USB 3.0 hub(such as VIA's)
doesn't respond the address device command after resume. The
root cause is the superspeed hub will miss the Hub Depth value
that is used as an offset into the route string to locate the
bits it uses to determine the downstream port number after
reset, and all packets can't be routed to the device attached
to the superspeed hub.

Hub driver sends a Set Hub Depth request to the superspeed hub
except for USB 3.0 root hub when the hub is initialized and
doesn't send the request again after reset due to the resume
process. So moving the code that sends the Set Hub Depth request
to the superspeed hub from hub_configure() to hub_activate()
is to cover those situations include initialization and reset.

The patch should be backported to kernels as old as 2.6.39.

Signed-off-by: Elric Fu &lt;elricfu1@gmail.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a45aa3b30583e7d54e7cf4fbcd0aa699348a6e5c upstream.

The superspeed device attached to a USB 3.0 hub(such as VIA's)
doesn't respond the address device command after resume. The
root cause is the superspeed hub will miss the Hub Depth value
that is used as an offset into the route string to locate the
bits it uses to determine the downstream port number after
reset, and all packets can't be routed to the device attached
to the superspeed hub.

Hub driver sends a Set Hub Depth request to the superspeed hub
except for USB 3.0 root hub when the hub is initialized and
doesn't send the request again after reset due to the resume
process. So moving the code that sends the Set Hub Depth request
to the superspeed hub from hub_configure() to hub_activate()
is to cover those situations include initialization and reset.

The patch should be backported to kernels as old as 2.6.39.

Signed-off-by: Elric Fu &lt;elricfu1@gmail.com&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
