<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/usb/host, branch v4.9.15</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: host: xhci: plat: check hcc_params after add hcd</title>
<updated>2017-03-12T05:41:48+00:00</updated>
<author>
<name>William wu</name>
<email>william.wu@rock-chips.com</email>
</author>
<published>2017-01-17T07:32:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=82bd560d9552a7b30ad1123591de63684fe0a63e'/>
<id>82bd560d9552a7b30ad1123591de63684fe0a63e</id>
<content type='text'>
commit 5de4e1ea9a731cad195ce5152705c21daef3bbba upstream.

The commit 4ac53087d6d4 ("usb: xhci: plat: Create both
HCDs before adding them") move add hcd to the end of
probe, this cause hcc_params uninitiated, because xHCI
driver sets hcc_params in xhci_gen_setup() called from
usb_add_hcd().

This patch checks the Maximum Primary Stream Array Size
in the hcc_params register after add primary hcd.

Signed-off-by: William wu &lt;william.wu@rock-chips.com&gt;
Acked-by: Roger Quadros &lt;rogerq@ti.com&gt;
Fixes: 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them")
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 5de4e1ea9a731cad195ce5152705c21daef3bbba upstream.

The commit 4ac53087d6d4 ("usb: xhci: plat: Create both
HCDs before adding them") move add hcd to the end of
probe, this cause hcc_params uninitiated, because xHCI
driver sets hcc_params in xhci_gen_setup() called from
usb_add_hcd().

This patch checks the Maximum Primary Stream Array Size
in the hcc_params register after add primary hcd.

Signed-off-by: William wu &lt;william.wu@rock-chips.com&gt;
Acked-by: Roger Quadros &lt;rogerq@ti.com&gt;
Fixes: 4ac53087d6d4 ("usb: xhci: plat: Create both HCDs before adding them")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: fix deadlock at host remove by running watchdog correctly</title>
<updated>2017-01-19T19:18:02+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-01-11T15:10:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4d0f302bf56a03b8023f06a27b811c1a4625c20d'/>
<id>4d0f302bf56a03b8023f06a27b811c1a4625c20d</id>
<content type='text'>
commit d6169d04097fd9ddf811e63eae4e5cd71e6666e2 upstream.

If a URB is killed while the host is removed we can end up in a situation
where the hub thread takes the roothub device lock, and waits for
the URB to be given back by xhci-hcd, blocking the host remove code.

xhci-hcd tries to stop the endpoint and give back the urb, but can't
as the host is removed from PCI bus at the same time, preventing the normal
way of giving back urb.

Instead we need to rely on the stop command timeout function to give back
the urb. This xhci_stop_endpoint_command_watchdog() timeout function
used a XHCI_STATE_DYING flag to indicate if the timeout function is already
running, but later this flag has been taking into use in other places to
mark that xhci is dying.

Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
checking that reading from pci state does not return 0xffffffff or that
host is not halted before trying to stop the endpoint.

This whole area of stopping endpoints, giving back URBs, and the wathdog
timeout need rework, this fix focuses on solving a specific deadlock
issue that we can then send to stable before any major rework.

Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 d6169d04097fd9ddf811e63eae4e5cd71e6666e2 upstream.

If a URB is killed while the host is removed we can end up in a situation
where the hub thread takes the roothub device lock, and waits for
the URB to be given back by xhci-hcd, blocking the host remove code.

xhci-hcd tries to stop the endpoint and give back the urb, but can't
as the host is removed from PCI bus at the same time, preventing the normal
way of giving back urb.

Instead we need to rely on the stop command timeout function to give back
the urb. This xhci_stop_endpoint_command_watchdog() timeout function
used a XHCI_STATE_DYING flag to indicate if the timeout function is already
running, but later this flag has been taking into use in other places to
mark that xhci is dying.

Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
checking that reading from pci state does not return 0xffffffff or that
host is not halted before trying to stop the endpoint.

This whole area of stopping endpoints, giving back URBs, and the wathdog
timeout need rework, this fix focuses on solving a specific deadlock
issue that we can then send to stable before any major rework.

Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Fix race related to abort operation</title>
<updated>2017-01-12T10:39:17+00:00</updated>
<author>
<name>OGAWA Hirofumi</name>
<email>hirofumi@mail.parknet.co.jp</email>
</author>
<published>2017-01-03T16:28:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=63d92d10a8208afeed87522a4b4b09e309c8622a'/>
<id>63d92d10a8208afeed87522a4b4b09e309c8622a</id>
<content type='text'>
commit 1c111b6c3844a142e03bcfc2fa17bfbdea08e9dc upstream.

Current abort operation has race.

    xhci_handle_command_timeout()
      xhci_abort_cmd_ring()
        xhci_write_64(CMD_RING_ABORT)
        xhci_handshake(5s)
	  do {
	    check CMD_RING_RUNNING
            udelay(1)
					 ...
					 COMP_CMD_ABORT event
					 COMP_CMD_STOP event
					 xhci_handle_stopped_cmd_ring()
					   restart cmd_ring
                                           CMD_RING_RUNNING become 1 again
	  } while ()
          return -ETIMEDOUT
        xhci_write_64(CMD_RING_ABORT)
        /* can abort random command */

To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.

But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).

To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring().  And timeout handler waits COMP_CMD_STOP event.

At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().

[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]

[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 1c111b6c3844a142e03bcfc2fa17bfbdea08e9dc upstream.

Current abort operation has race.

    xhci_handle_command_timeout()
      xhci_abort_cmd_ring()
        xhci_write_64(CMD_RING_ABORT)
        xhci_handshake(5s)
	  do {
	    check CMD_RING_RUNNING
            udelay(1)
					 ...
					 COMP_CMD_ABORT event
					 COMP_CMD_STOP event
					 xhci_handle_stopped_cmd_ring()
					   restart cmd_ring
                                           CMD_RING_RUNNING become 1 again
	  } while ()
          return -ETIMEDOUT
        xhci_write_64(CMD_RING_ABORT)
        /* can abort random command */

To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.

But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).

To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring().  And timeout handler waits COMP_CMD_STOP event.

At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().

[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]

[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Use delayed_work instead of timer for command timeout</title>
<updated>2017-01-12T10:39:17+00:00</updated>
<author>
<name>OGAWA Hirofumi</name>
<email>hirofumi@mail.parknet.co.jp</email>
</author>
<published>2017-01-03T16:28:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=799dfdeb33a0f8d08c4a6d6781b20a4011825ee4'/>
<id>799dfdeb33a0f8d08c4a6d6781b20a4011825ee4</id>
<content type='text'>
commit cb4d5ce588c5ff68e0fdd30370a0e6bc2c0a736b upstream.

This is preparation to fix abort operation race (See "xhci: Fix race
related to abort operation"). To make timeout sleepable, use
delayed_work instead of timer.

[change a newly added pending timer fix to pending work -Mathias]
Signed-off-by: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 cb4d5ce588c5ff68e0fdd30370a0e6bc2c0a736b upstream.

This is preparation to fix abort operation race (See "xhci: Fix race
related to abort operation"). To make timeout sleepable, use
delayed_work instead of timer.

[change a newly added pending timer fix to pending work -Mathias]
Signed-off-by: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: xhci-mem: use passed in GFP flags instead of GFP_KERNEL</title>
<updated>2017-01-12T10:39:17+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2016-11-10T19:33:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6db52153fea3c4cca32712106202955d034e7fad'/>
<id>6db52153fea3c4cca32712106202955d034e7fad</id>
<content type='text'>
commit c95a9f83711bf53faeb4ed9bbb63a3f065613dfb upstream.

We normally use the passed in gfp flags for allocations, it's just these
two which were missed.

Fixes: 22d45f01a836 ("usb/xhci: replace pci_*_consistent() with dma_*_coherent()")
Cc: Mathias Nyman &lt;mathias.nyman@intel.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&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 c95a9f83711bf53faeb4ed9bbb63a3f065613dfb upstream.

We normally use the passed in gfp flags for allocations, it's just these
two which were missed.

Fixes: 22d45f01a836 ("usb/xhci: replace pci_*_consistent() with dma_*_coherent()")
Cc: Mathias Nyman &lt;mathias.nyman@intel.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Acked-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: return error code when platform_get_irq fails</title>
<updated>2017-01-12T10:39:13+00:00</updated>
<author>
<name>Pan Bian</name>
<email>bianpan2016@163.com</email>
</author>
<published>2017-01-03T16:28:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9acba5179d6c08f5499de52cb543d2b2fbb98cc2'/>
<id>9acba5179d6c08f5499de52cb543d2b2fbb98cc2</id>
<content type='text'>
commit 28bedb5ae463b9f7e5195cbc93f1795e374bdef8 upstream.

In function xhci_mtk_probe(), variable ret takes the return value. Its
value should be negative on failures. However, when the call to function
platform_get_irq() fails, it does not set the error code, and 0 will be
returned. 0 indicates no error. As a result, the callers of function
xhci_mtk_probe() will not be able to detect the error. This patch fixes
the bug by assigning the return value of platform_get_irq() to variable
ret if it fails.

Signed-off-by: Pan Bian &lt;bianpan2016@163.com&gt;
Reviewed-by: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 28bedb5ae463b9f7e5195cbc93f1795e374bdef8 upstream.

In function xhci_mtk_probe(), variable ret takes the return value. Its
value should be negative on failures. However, when the call to function
platform_get_irq() fails, it does not set the error code, and 0 will be
returned. 0 indicates no error. As a result, the callers of function
xhci_mtk_probe() will not be able to detect the error. This patch fixes
the bug by assigning the return value of platform_get_irq() to variable
ret if it fails.

Signed-off-by: Pan Bian &lt;bianpan2016@163.com&gt;
Reviewed-by: Matthias Brugger &lt;matthias.bgg@gmail.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: xhci: hold lock over xhci_abort_cmd_ring()</title>
<updated>2017-01-12T10:39:12+00:00</updated>
<author>
<name>Lu Baolu</name>
<email>baolu.lu@linux.intel.com</email>
</author>
<published>2017-01-03T16:28:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cb02cce9a7f8eea6f6c8432f296074d20829ff0f'/>
<id>cb02cce9a7f8eea6f6c8432f296074d20829ff0f</id>
<content type='text'>
commit 4dea70778c0f48b4385c7720c363ec8d37a401b4 upstream.

In command timer function, xhci_handle_command_timeout(), xhci-&gt;lock
is unlocked before call into xhci_abort_cmd_ring(). This might cause
race between the timer function and the event handler.

The xhci_abort_cmd_ring() function sets the CMD_RING_ABORT bit in the
command register and polling it until the setting takes effect. A stop
command ring event might be handled between writing the abort bit and
polling for it. The event handler will restart the command ring, which
causes the failure of polling, and we ever believed that we failed to
stop it.

As a bonus, this also fixes some issues of calling functions without
locking in xhci_handle_command_timeout().

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 4dea70778c0f48b4385c7720c363ec8d37a401b4 upstream.

In command timer function, xhci_handle_command_timeout(), xhci-&gt;lock
is unlocked before call into xhci_abort_cmd_ring(). This might cause
race between the timer function and the event handler.

The xhci_abort_cmd_ring() function sets the CMD_RING_ABORT bit in the
command register and polling it until the setting takes effect. A stop
command ring event might be handled between writing the abort bit and
polling for it. The event handler will restart the command ring, which
causes the failure of polling, and we ever believed that we failed to
stop it.

As a bonus, this also fixes some issues of calling functions without
locking in xhci_handle_command_timeout().

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xhci: Handle command completion and timeout race</title>
<updated>2017-01-12T10:39:12+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-01-03T16:28:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9e6c400bb58220c46a2e5e616a1fbf756f011489'/>
<id>9e6c400bb58220c46a2e5e616a1fbf756f011489</id>
<content type='text'>
commit a5a1b9514154437aa1ed35c291191f82fd3e941a upstream.

If we get a command completion event at the same time as the command
timeout work starts on another cpu we might end up aborting the wrong
command.

If the command completion takes the xhci lock before the timeout work, it
will handle the command, pick the next command, mark it as current_cmd, and
re-queue the timeout work. When the timeout work finally gets the lock
It will start aborting the wrong command.

This case can be resolved by checking if the timeout work is pending inside
the timeout function itself. A new timeout work can only be pending if the
command completed and a new command was queued.

If there are no more commands pending then command completion will set
the current_cmd to NULL, which is already handled in the timeout work.

Reported-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 a5a1b9514154437aa1ed35c291191f82fd3e941a upstream.

If we get a command completion event at the same time as the command
timeout work starts on another cpu we might end up aborting the wrong
command.

If the command completion takes the xhci lock before the timeout work, it
will handle the command, pick the next command, mark it as current_cmd, and
re-queue the timeout work. When the timeout work finally gets the lock
It will start aborting the wrong command.

This case can be resolved by checking if the timeout work is pending inside
the timeout function itself. A new timeout work can only be pending if the
command completed and a new command was queued.

If there are no more commands pending then command completion will set
the current_cmd to NULL, which is already handled in the timeout work.

Reported-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: host: xhci: Fix possible wild pointer when handling abort command</title>
<updated>2017-01-12T10:39:12+00:00</updated>
<author>
<name>Baolin Wang</name>
<email>baolin.wang@linaro.org</email>
</author>
<published>2017-01-03T16:28:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=78ccc1966c9e3dc379a89fb3efb06db35a297680'/>
<id>78ccc1966c9e3dc379a89fb3efb06db35a297680</id>
<content type='text'>
commit 2a7cfdf37b7c08ac29df4c62ea5ccb01474b6597 upstream.

When current command was supposed to be aborted, host will free the command
in handle_cmd_completion() function. But it might be still referenced by
xhci-&gt;current_cmd, which need to set NULL.

Signed-off-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 2a7cfdf37b7c08ac29df4c62ea5ccb01474b6597 upstream.

When current command was supposed to be aborted, host will free the command
in handle_cmd_completion() function. But it might be still referenced by
xhci-&gt;current_cmd, which need to set NULL.

Signed-off-by: Baolin Wang &lt;baolin.wang@linaro.org&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: xhci: fix return value of xhci_setup_device()</title>
<updated>2017-01-12T10:39:12+00:00</updated>
<author>
<name>Lu Baolu</name>
<email>baolu.lu@linux.intel.com</email>
</author>
<published>2017-01-03T16:28:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=a2118d0974095b994a8aa7b32a6a213b961f4f3e'/>
<id>a2118d0974095b994a8aa7b32a6a213b961f4f3e</id>
<content type='text'>
commit 90797aee5d6902b49a453c97d83c326408aeb5a8 upstream.

xhci_setup_device() should return failure with correct error number
when xhci host has died, removed or halted.

During usb device enumeration, if usb host is not accessible (died,
removed or halted), the hc_driver-&gt;address_device() should return
a corresponding error code to usb core. But current xhci driver just
returns success. This misleads usb core to continue the enumeration
by reading the device descriptor, which will result in failure, and
users will get a misleading message like "device descriptor read/8,
error -110".

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@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 90797aee5d6902b49a453c97d83c326408aeb5a8 upstream.

xhci_setup_device() should return failure with correct error number
when xhci host has died, removed or halted.

During usb device enumeration, if usb host is not accessible (died,
removed or halted), the hc_driver-&gt;address_device() should return
a corresponding error code to usb core. But current xhci driver just
returns success. This misleads usb core to continue the enumeration
by reading the device descriptor, which will result in failure, and
users will get a misleading message like "device descriptor read/8,
error -110".

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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