<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/usb/host, branch v4.9.69</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>usb: host: fix incorrect updating of offset</title>
<updated>2017-12-09T21:01:57+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2017-11-07T16:45:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=08dd03812e8b1dba97eb00092a8cfbe8a7ebc13c'/>
<id>08dd03812e8b1dba97eb00092a8cfbe8a7ebc13c</id>
<content type='text'>
commit 1d5a31582ef046d3b233f0da1a68ae26519b2f0a upstream.

The variable temp is incorrectly being updated, instead it should
be offset otherwise the loop just reads the same capability value
and loops forever.  Thanks to Alan Stern for pointing out the
correct fix to my original fix.  Fix also cleans up clang warning:

drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp'
is never read

Fixes: d49d43174400 ("USB: misc ehci updates")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.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 1d5a31582ef046d3b233f0da1a68ae26519b2f0a upstream.

The variable temp is incorrectly being updated, instead it should
be offset otherwise the loop just reads the same capability value
and loops forever.  Thanks to Alan Stern for pointing out the
correct fix to my original fix.  Fix also cleans up clang warning:

drivers/usb/host/ehci-dbg.c:840:4: warning: Value stored to 'temp'
is never read

Fixes: d49d43174400 ("USB: misc ehci updates")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.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>
<entry>
<title>usb: xhci: fix panic in xhci_free_virt_devices_depth_first</title>
<updated>2017-12-09T21:01:56+00:00</updated>
<author>
<name>Yu Chen</name>
<email>chenyu56@huawei.com</email>
</author>
<published>2017-12-01T11:41:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=34ba2f04a480101c3d60918a45f68ff66973ef49'/>
<id>34ba2f04a480101c3d60918a45f68ff66973ef49</id>
<content type='text'>
commit 80e457699a8dbdd70f2d26911e46f538645c55fc upstream.

Check vdev-&gt;real_port 0 to avoid panic
[    9.261347] [&lt;ffffff800884a390&gt;] xhci_free_virt_devices_depth_first+0x58/0x108
[    9.261352] [&lt;ffffff800884a814&gt;] xhci_mem_cleanup+0x1bc/0x570
[    9.261355] [&lt;ffffff8008842de8&gt;] xhci_stop+0x140/0x1c8
[    9.261365] [&lt;ffffff80087ed304&gt;] usb_remove_hcd+0xfc/0x1d0
[    9.261369] [&lt;ffffff80088551c4&gt;] xhci_plat_remove+0x6c/0xa8
[    9.261377] [&lt;ffffff80086e928c&gt;] platform_drv_remove+0x2c/0x70
[    9.261384] [&lt;ffffff80086e6ea0&gt;] __device_release_driver+0x80/0x108
[    9.261387] [&lt;ffffff80086e7a1c&gt;] device_release_driver+0x2c/0x40
[    9.261392] [&lt;ffffff80086e5f28&gt;] bus_remove_device+0xe0/0x120
[    9.261396] [&lt;ffffff80086e2e34&gt;] device_del+0x114/0x210
[    9.261399] [&lt;ffffff80086e9e00&gt;] platform_device_del+0x30/0xa0
[    9.261403] [&lt;ffffff8008810bdc&gt;] dwc3_otg_work+0x204/0x488
[    9.261407] [&lt;ffffff80088133fc&gt;] event_work+0x304/0x5b8
[    9.261414] [&lt;ffffff80080e31b0&gt;] process_one_work+0x148/0x490
[    9.261417] [&lt;ffffff80080e3548&gt;] worker_thread+0x50/0x4a0
[    9.261421] [&lt;ffffff80080e9ea0&gt;] kthread+0xe8/0x100
[    9.261427] [&lt;ffffff8008083680&gt;] ret_from_fork+0x10/0x50

The problem can occur if xhci_plat_remove() is called shortly after
xhci_plat_probe(). While xhci_free_virt_devices_depth_first been
called before the device has been setup and get real_port initialized.
The problem occurred on Hikey960 and was reproduced by Guenter Roeck
on Kevin with chromeos-4.4.

Fixes: ee8665e28e8d ("xhci: free xhci virtual devices with leaf nodes first")
Cc: Guenter Roeck &lt;groeck@google.com&gt;
Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Fan Ning &lt;fanning4@hisilicon.com&gt;
Signed-off-by: Li Rui &lt;lirui39@hisilicon.com&gt;
Signed-off-by: yangdi &lt;yangdi10@hisilicon.com&gt;
Signed-off-by: Yu Chen &lt;chenyu56@huawei.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 80e457699a8dbdd70f2d26911e46f538645c55fc upstream.

Check vdev-&gt;real_port 0 to avoid panic
[    9.261347] [&lt;ffffff800884a390&gt;] xhci_free_virt_devices_depth_first+0x58/0x108
[    9.261352] [&lt;ffffff800884a814&gt;] xhci_mem_cleanup+0x1bc/0x570
[    9.261355] [&lt;ffffff8008842de8&gt;] xhci_stop+0x140/0x1c8
[    9.261365] [&lt;ffffff80087ed304&gt;] usb_remove_hcd+0xfc/0x1d0
[    9.261369] [&lt;ffffff80088551c4&gt;] xhci_plat_remove+0x6c/0xa8
[    9.261377] [&lt;ffffff80086e928c&gt;] platform_drv_remove+0x2c/0x70
[    9.261384] [&lt;ffffff80086e6ea0&gt;] __device_release_driver+0x80/0x108
[    9.261387] [&lt;ffffff80086e7a1c&gt;] device_release_driver+0x2c/0x40
[    9.261392] [&lt;ffffff80086e5f28&gt;] bus_remove_device+0xe0/0x120
[    9.261396] [&lt;ffffff80086e2e34&gt;] device_del+0x114/0x210
[    9.261399] [&lt;ffffff80086e9e00&gt;] platform_device_del+0x30/0xa0
[    9.261403] [&lt;ffffff8008810bdc&gt;] dwc3_otg_work+0x204/0x488
[    9.261407] [&lt;ffffff80088133fc&gt;] event_work+0x304/0x5b8
[    9.261414] [&lt;ffffff80080e31b0&gt;] process_one_work+0x148/0x490
[    9.261417] [&lt;ffffff80080e3548&gt;] worker_thread+0x50/0x4a0
[    9.261421] [&lt;ffffff80080e9ea0&gt;] kthread+0xe8/0x100
[    9.261427] [&lt;ffffff8008083680&gt;] ret_from_fork+0x10/0x50

The problem can occur if xhci_plat_remove() is called shortly after
xhci_plat_probe(). While xhci_free_virt_devices_depth_first been
called before the device has been setup and get real_port initialized.
The problem occurred on Hikey960 and was reproduced by Guenter Roeck
on Kevin with chromeos-4.4.

Fixes: ee8665e28e8d ("xhci: free xhci virtual devices with leaf nodes first")
Cc: Guenter Roeck &lt;groeck@google.com&gt;
Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Fan Ning &lt;fanning4@hisilicon.com&gt;
Signed-off-by: Li Rui &lt;lirui39@hisilicon.com&gt;
Signed-off-by: yangdi &lt;yangdi10@hisilicon.com&gt;
Signed-off-by: Yu Chen &lt;chenyu56@huawei.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: Handle error condition in xhci_stop_device()</title>
<updated>2017-11-02T08:49:13+00:00</updated>
<author>
<name>Mayank Rana</name>
<email>mrana@codeaurora.org</email>
</author>
<published>2017-10-06T14:45:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=659b04ad201b6ce71bdced1653e41c9944066f40'/>
<id>659b04ad201b6ce71bdced1653e41c9944066f40</id>
<content type='text'>
commit b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd upstream.

xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Signed-off-by: Mayank Rana &lt;mrana@codeaurora.org&gt;
Signed-off-by: Jack Pham &lt;jackp@codeaurora.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 b3207c65dfafae27e7c492cb9188c0dc0eeaf3fd upstream.

xhci_stop_device() calls xhci_queue_stop_endpoint() multiple times
without checking the return value. xhci_queue_stop_endpoint() can
return error if the HC is already halted or unable to queue commands.
This can cause a deadlock condition as xhci_stop_device() would
end up waiting indefinitely for a completion for the command that
didn't get queued. Fix this by checking the return value and bailing
out of xhci_stop_device() in case of error. This patch happens to fix
potential memory leaks of the allocated command structures as well.

Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,")
Signed-off-by: Mayank Rana &lt;mrana@codeaurora.org&gt;
Signed-off-by: Jack Pham &lt;jackp@codeaurora.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>xhci: Identify USB 3.1 capable hosts by their port protocol capability</title>
<updated>2017-10-27T08:38:06+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-10-06T14:45:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dc1858a8e56f2ee9697d9cc5d062f68894ef006e'/>
<id>dc1858a8e56f2ee9697d9cc5d062f68894ef006e</id>
<content type='text'>
commit ea7d0d69426cab6747ed311c53f4142eb48b9454 upstream.

Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0

xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.

Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.

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 ea7d0d69426cab6747ed311c53f4142eb48b9454 upstream.

Many USB 3.1 capable hosts never updated the Serial Bus Release Number
(SBRN) register to USB 3.1 from USB 3.0

xhci driver identified USB 3.1 capable hosts based on this SBRN register,
which according to specs "contains the release of the Universal Serial
Bus Specification with which this Universal Serial Bus Host Controller
module is compliant." but still in october 2017 gives USB 3.0 as
the only possible option.

Make an additional check for USB 3.1 support and enable it if the xHCI
supported protocol capablity lists USB 3.1 capable ports.

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>Revert "xhci: Limit USB2 port wake support for AMD Promontory hosts"</title>
<updated>2017-10-12T09:51:18+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2017-09-18T14:39:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a13481f8cdca4e3f08d950e230f49742d95fc70c'/>
<id>a13481f8cdca4e3f08d950e230f49742d95fc70c</id>
<content type='text'>
commit bcd6a7aa13800afc1418e6b29d944d882214939a upstream.

This reverts commit dec08194ffeccfa1cf085906b53d301930eae18f.

Commit dec08194ffec ("xhci: Limit USB2 port wake support for AMD Promontory
hosts") makes all high speed USB ports on ASUS PRIME B350M-A cease to
function after enabling runtime PM.

All boards with this chipsets will be affected, so revert the commit.

The original patch was added to stable 4.9, 4.11 and 4.12 and needs
to reverted from there as well

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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 bcd6a7aa13800afc1418e6b29d944d882214939a upstream.

This reverts commit dec08194ffeccfa1cf085906b53d301930eae18f.

Commit dec08194ffec ("xhci: Limit USB2 port wake support for AMD Promontory
hosts") makes all high speed USB ports on ASUS PRIME B350M-A cease to
function after enabling runtime PM.

All boards with this chipsets will be affected, so revert the commit.

The original patch was added to stable 4.9, 4.11 and 4.12 and needs
to reverted from there as well

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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: set missing SuperSpeedPlus Link Protocol bit in roothub descriptor</title>
<updated>2017-10-12T09:51:18+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-09-18T14:39:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f77615db8ae850ef196843502b1d0aaae8e173d2'/>
<id>f77615db8ae850ef196843502b1d0aaae8e173d2</id>
<content type='text'>
commit 7bea22b124d77845c85a62eaa29a85ba6cc2f899 upstream.

A SuperSpeedPlus roothub needs to have the Link Protocol (LP) bit set in
the bmSublinkSpeedAttr[] entry of a SuperSpeedPlus descriptor.

If the xhci controller has an optional Protocol Speed ID (PSI) table then
that will be used as a base to create the roothub SuperSpeedPlus
descriptor.
The PSI table does not however necessary contain the LP bit so we need
to set it manually.

Check the psi speed and set LP bit if speed is 10Gbps or higher.
We're not setting it for 5 to 10Gbps as USB 3.1 specification always
mention SuperSpeedPlus for 10Gbps or higher, and some SSIC USB 3.0 speeds
can be over 5Gbps, such as SSIC-G3B-L1 at 5830 Mbps

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 7bea22b124d77845c85a62eaa29a85ba6cc2f899 upstream.

A SuperSpeedPlus roothub needs to have the Link Protocol (LP) bit set in
the bmSublinkSpeedAttr[] entry of a SuperSpeedPlus descriptor.

If the xhci controller has an optional Protocol Speed ID (PSI) table then
that will be used as a base to create the roothub SuperSpeedPlus
descriptor.
The PSI table does not however necessary contain the LP bit so we need
to set it manually.

Check the psi speed and set LP bit if speed is 10Gbps or higher.
We're not setting it for 5 to 10Gbps as USB 3.1 specification always
mention SuperSpeedPlus for 10Gbps or higher, and some SSIC USB 3.0 speeds
can be over 5Gbps, such as SSIC-G3B-L1 at 5830 Mbps

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 sleeping with spin_lock_irq() held in ASmedia 1042A workaround</title>
<updated>2017-10-12T09:51:18+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-09-18T14:39:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f1a04773d773900cd2f670b18c20c86a4218420f'/>
<id>f1a04773d773900cd2f670b18c20c86a4218420f</id>
<content type='text'>
commit 4ec1cd3eeeee7ccc35681270da028dbc29ca7bbd upstream.

The flow control workaround for ASM1042A xHC hosts sleeps between
register polling. The workaround gets called in several places, among
them with spin_lock_irq() held when xHC host is resumed or hoplug removed.

This was noticed as kernel panics at resume on a Dell XPS15 9550 with
TB16 thunderbolt dock.

Avoid sleeping with spin_lock_irq() held, use udelay() instead

The original workaround was added to 4.9 and 4.12 stable releases,
this patch needs to be applied to those as well.

Fixes: 9da5a1092b13 ("xhci: Bad Ethernet performance plugged in ASM1042A host")
Reported-by: Jose Marino &lt;marinoj@nso.edu&gt;
Tested-by: Jose Marino &lt;marinoj@nso.edu&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 4ec1cd3eeeee7ccc35681270da028dbc29ca7bbd upstream.

The flow control workaround for ASM1042A xHC hosts sleeps between
register polling. The workaround gets called in several places, among
them with spin_lock_irq() held when xHC host is resumed or hoplug removed.

This was noticed as kernel panics at resume on a Dell XPS15 9550 with
TB16 thunderbolt dock.

Avoid sleeping with spin_lock_irq() held, use udelay() instead

The original workaround was added to 4.9 and 4.12 stable releases,
this patch needs to be applied to those as well.

Fixes: 9da5a1092b13 ("xhci: Bad Ethernet performance plugged in ASM1042A host")
Reported-by: Jose Marino &lt;marinoj@nso.edu&gt;
Tested-by: Jose Marino &lt;marinoj@nso.edu&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: fix finding correct bus_state structure for USB 3.1 hosts</title>
<updated>2017-10-12T09:51:17+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2017-09-18T14:39:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=67e752e1d60f9f40b8391dad48f7c842bdba6ec4'/>
<id>67e752e1d60f9f40b8391dad48f7c842bdba6ec4</id>
<content type='text'>
commit 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c upstream.

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared
for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

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 5a838a13c9b4e5dd188b7a6eaeb894e9358ead0c upstream.

xhci driver keeps a bus_state structure for each hcd (usb2 and usb3)

The structure is picked based on hcd speed, but driver only compared
for HCD_USB3 speed, returning the wrong bus_state for HCD_USB31 hosts.

This caused null pointer dereference errors in bus_resume function.

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: pci-quirks.c: Corrected timeout values used in handshake</title>
<updated>2017-10-12T09:51:16+00:00</updated>
<author>
<name>Jim Dickerson</name>
<email>jim.dickerson@hpe.com</email>
</author>
<published>2017-09-18T14:39:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0b104f92ed217a2e47a832928f23dd807eeebcd6'/>
<id>0b104f92ed217a2e47a832928f23dd807eeebcd6</id>
<content type='text'>
commit 114ec3a6f9096d211a4aff4277793ba969a62c73 upstream.

Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were made with milliseconds
not microseconds. Comments referenced 5 seconds not 1 second as
in specs.

The wrong units were also corrected in a second handshake call.

Signed-off-by: Jim Dickerson &lt;jim.dickerson@hpe.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 114ec3a6f9096d211a4aff4277793ba969a62c73 upstream.

Servers were emitting failed handoff messages but were not
waiting the full 1 second as designated in section 4.22.1 of
the eXtensible Host Controller Interface specifications. The
handshake was using wrong units so calls were made with milliseconds
not microseconds. Comments referenced 5 seconds not 1 second as
in specs.

The wrong units were also corrected in a second handshake call.

Signed-off-by: Jim Dickerson &lt;jim.dickerson@hpe.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: make the MTK XHCI driver compile for older MIPS SoCs</title>
<updated>2017-10-08T08:26:04+00:00</updated>
<author>
<name>John Crispin</name>
<email>john@phrozen.org</email>
</author>
<published>2016-12-20T18:08:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d74f860528fbd0cde7127b617d7695bbc68d8e0f'/>
<id>d74f860528fbd0cde7127b617d7695bbc68d8e0f</id>
<content type='text'>
[ Upstream commit 808cf33d4817c730008de9b2736b357708a3d7f6 ]

The MIPS based MT7621 shares the same XHCI core as the newer generation of
ARM based SoCs. The driver works out of the box and we only need to make it
buildable in Kconfig.

Signed-off-by: John Crispin &lt;john@phrozen.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.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>
[ Upstream commit 808cf33d4817c730008de9b2736b357708a3d7f6 ]

The MIPS based MT7621 shares the same XHCI core as the newer generation of
ARM based SoCs. The driver works out of the box and we only need to make it
buildable in Kconfig.

Signed-off-by: John Crispin &lt;john@phrozen.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
