<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux/usb, branch linux-3.18.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>usb: gadget: composite: fix incorrect handling of OS desc requests</title>
<updated>2018-05-30T05:47:42+00:00</updated>
<author>
<name>Chris Dickens</name>
<email>christopher.a.dickens@gmail.com</email>
</author>
<published>2018-01-01T02:59:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=40c1020f0ef83fc07b0d746bc71ff88151508fe3'/>
<id>40c1020f0ef83fc07b0d746bc71ff88151508fe3</id>
<content type='text'>
[ Upstream commit 5d6ae4f0da8a64a185074dabb1b2f8c148efa741 ]

When handling an OS descriptor request, one of the first operations is
to zero out the request buffer using the wLength from the setup packet.
There is no bounds checking, so a wLength &gt; 4096 would clobber memory
adjacent to the request buffer. Fix this by taking the min of wLength
and the request buffer length prior to the memset. While at it, define
the buffer length in a header file so that magic numbers don't appear
throughout the code.

When returning data to the host, the data length should be the min of
the wLength and the valid data we have to return. Currently we are
returning wLength, thus requests for a wLength greater than the amount
of data in the OS descriptor buffer would return invalid (albeit zero'd)
data following the valid descriptor data. Fix this by counting the
number of bytes when constructing the data and using this when
determining the length of the request.

Signed-off-by: Chris Dickens &lt;christopher.a.dickens@gmail.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.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 5d6ae4f0da8a64a185074dabb1b2f8c148efa741 ]

When handling an OS descriptor request, one of the first operations is
to zero out the request buffer using the wLength from the setup packet.
There is no bounds checking, so a wLength &gt; 4096 would clobber memory
adjacent to the request buffer. Fix this by taking the min of wLength
and the request buffer length prior to the memset. While at it, define
the buffer length in a header file so that magic numbers don't appear
throughout the code.

When returning data to the host, the data length should be the min of
the wLength and the valid data we have to return. Currently we are
returning wLength, thus requests for a wLength greater than the amount
of data in the OS descriptor buffer would return invalid (albeit zero'd)
data following the valid descriptor data. Fix this by counting the
number of bytes when constructing the data and using this when
determining the length of the request.

Signed-off-by: Chris Dickens &lt;christopher.a.dickens@gmail.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: gadget: fix usb_ep_align_maybe endianness and new usb_ep_align</title>
<updated>2018-04-08T09:49:44+00:00</updated>
<author>
<name>Felipe F. Tonello</name>
<email>eu@felipetonello.com</email>
</author>
<published>2016-08-08T20:30:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7757f7309913e77ef71f73e58b7ed4807bd51c0c'/>
<id>7757f7309913e77ef71f73e58b7ed4807bd51c0c</id>
<content type='text'>
commit 16b114a6d7973cf027e4c2b23eae1076eaf98c25 upstream.

USB spec specifies wMaxPacketSize to be little endian (as other properties),
so when using this variable in the driver we should convert to the current
CPU endianness if necessary.

This patch also introduces usb_ep_align() which does always returns the
aligned buffer size for an endpoint. This is useful to be used by USB requests
allocator functions.

Signed-off-by: Felipe F. Tonello &lt;eu@felipetonello.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@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 16b114a6d7973cf027e4c2b23eae1076eaf98c25 upstream.

USB spec specifies wMaxPacketSize to be little endian (as other properties),
so when using this variable in the driver we should convert to the current
CPU endianness if necessary.

This patch also introduces usb_ep_align() which does always returns the
aligned buffer size for an endpoint. This is useful to be used by USB requests
allocator functions.

Signed-off-by: Felipe F. Tonello &lt;eu@felipetonello.com&gt;
Signed-off-by: Felipe Balbi &lt;felipe.balbi@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: quirks: add control message delay for 1b1c:1b20</title>
<updated>2018-03-18T10:15:44+00:00</updated>
<author>
<name>Danilo Krummrich</name>
<email>danilokrummrich@dk-develop.de</email>
</author>
<published>2018-03-06T08:38:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5ad9d27c1244b3444de02396e1fffe99d21b8d90'/>
<id>5ad9d27c1244b3444de02396e1fffe99d21b8d90</id>
<content type='text'>
commit cb88a0588717ba6c756cb5972d75766b273a6817 upstream.

Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.

Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.

Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):

[   29.103520] usb 1-8: string descriptor 0 read error: -110
[   34.363097] usb 1-8: can't set config #1, error -110

Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:

[   35.400533] usbhid 1-8:1.0: can't add hid device: -110
[   35.401014] usbhid: probe of 1-8:1.0 failed with error -110

The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.

Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().

The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.

Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable@vger.kernel.org
Signed-off-by: Danilo Krummrich &lt;danilokrummrich@dk-develop.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 cb88a0588717ba6c756cb5972d75766b273a6817 upstream.

Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.

Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.

Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):

[   29.103520] usb 1-8: string descriptor 0 read error: -110
[   34.363097] usb 1-8: can't set config #1, error -110

Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:

[   35.400533] usbhid 1-8:1.0: can't add hid device: -110
[   35.401014] usbhid: probe of 1-8:1.0 failed with error -110

The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.

Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().

The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.

Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable@vger.kernel.org
Signed-off-by: Danilo Krummrich &lt;danilokrummrich@dk-develop.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>usb: Fix typo in the definition of Endpoint[out]Request</title>
<updated>2017-07-15T08:14:40+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2017-06-13T06:01:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e7ce85766bdda03194e33f2e5c2e8a959ed818b9'/>
<id>e7ce85766bdda03194e33f2e5c2e8a959ed818b9</id>
<content type='text'>
commit 7cf916bd639bd26db7214f2205bccdb4b9306256 upstream.

The current definition is wrong. This breaks my upcoming
Aspeed virtual hub driver.

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&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 7cf916bd639bd26db7214f2205bccdb4b9306256 upstream.

The current definition is wrong. This breaks my upcoming
Aspeed virtual hub driver.

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&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-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk</title>
<updated>2017-04-18T05:55:53+00:00</updated>
<author>
<name>Samuel Thibault</name>
<email>samuel.thibault@ens-lyon.org</email>
</author>
<published>2017-03-13T19:50:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b3f13aba40ef73f86c23c3b3825f953d7d403f69'/>
<id>b3f13aba40ef73f86c23c3b3825f953d7d403f69</id>
<content type='text'>
commit 3243367b209faed5c320a4e5f9a565ee2a2ba958 upstream.

Some USB 2.0 devices erroneously report millisecond values in
bInterval. The generic config code manages to catch most of them,
but in some cases it's not completely enough.

The case at stake here is a USB 2.0 braille device, which wants to
announce 10ms and thus sets bInterval to 10, but with the USB 2.0
computation that yields to 64ms.  It happens that one can type fast
enough to reach this interval and get the device buffers overflown,
leading to problematic latencies.  The generic config code does not
catch this case because the 64ms is considered a sane enough value.

This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
to mark devices which actually report milliseconds in bInterval,
and marks Vario Ultra devices as needing it.

Signed-off-by: Samuel Thibault &lt;samuel.thibault@ens-lyon.org&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 3243367b209faed5c320a4e5f9a565ee2a2ba958 upstream.

Some USB 2.0 devices erroneously report millisecond values in
bInterval. The generic config code manages to catch most of them,
but in some cases it's not completely enough.

The case at stake here is a USB 2.0 braille device, which wants to
announce 10ms and thus sets bInterval to 10, but with the USB 2.0
computation that yields to 64ms.  It happens that one can type fast
enough to reach this interval and get the device buffers overflown,
leading to problematic latencies.  The generic config code does not
catch this case because the 64ms is considered a sane enough value.

This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
to mark devices which actually report milliseconds in bInterval,
and marks Vario Ultra devices as needing it.

Signed-off-by: Samuel Thibault &lt;samuel.thibault@ens-lyon.org&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: renesas_usbhs: fix build warning if 64-bit architecture</title>
<updated>2017-02-08T08:43:05+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2015-09-29T09:21:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e721bf1497aa8b4d115126fa1994afc9932c849f'/>
<id>e721bf1497aa8b4d115126fa1994afc9932c849f</id>
<content type='text'>
commit 9ae7ce00cc1353155b1914bfc40e8362efef7d1c upstream.

This patch fixes the following warning if 64-bit architecture environment:

./drivers/usb/renesas_usbhs/common.c:496:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  dparam-&gt;type = of_id ? (u32)of_id-&gt;data : 0;

Acked-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.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 9ae7ce00cc1353155b1914bfc40e8362efef7d1c upstream.

This patch fixes the following warning if 64-bit architecture environment:

./drivers/usb/renesas_usbhs/common.c:496:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  dparam-&gt;type = of_id ? (u32)of_id-&gt;data : 0;

Acked-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>USB: EHCI: declare hostpc register as zero-length array</title>
<updated>2016-07-12T12:47:09+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2016-06-23T18:54:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4c2b0216cdf54e81f7c0e841b5bb1116701ae25b'/>
<id>4c2b0216cdf54e81f7c0e841b5bb1116701ae25b</id>
<content type='text'>
[ Upstream commit 7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd ]

The HOSTPC extension registers found in some EHCI implementations form
a variable-length array, with one element for each port.  Therefore
the hostpc field in struct ehci_regs should be declared as a
zero-length array, not a single-element array.

This fixes a problem reported by UBSAN.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Wilfried Klaebe &lt;linux-kernel@lebenslange-mailadresse.de&gt;
Tested-by: Wilfried Klaebe &lt;linux-kernel@lebenslange-mailadresse.de&gt;
CC: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7e8b3dfef16375dbfeb1f36a83eb9f27117c51fd ]

The HOSTPC extension registers found in some EHCI implementations form
a variable-length array, with one element for each port.  Therefore
the hostpc field in struct ehci_regs should be declared as a
zero-length array, not a single-element array.

This fixes a problem reported by UBSAN.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Wilfried Klaebe &lt;linux-kernel@lebenslange-mailadresse.de&gt;
Tested-by: Wilfried Klaebe &lt;linux-kernel@lebenslange-mailadresse.de&gt;
CC: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usb: core: hub: hub_port_init lock controller instead of bus</title>
<updated>2016-06-03T15:30:30+00:00</updated>
<author>
<name>Chris Bainbridge</name>
<email>chris.bainbridge@gmail.com</email>
</author>
<published>2016-04-25T12:48:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=42798984faa3d1a83cfc4f4a5ab99f13e6782ef9'/>
<id>42798984faa3d1a83cfc4f4a5ab99f13e6782ef9</id>
<content type='text'>
[ Upstream commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 ]

The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [&lt;ffffffff81b9bab7&gt;] schedule+0x37/0x90
 [&lt;ffffffff817da7cd&gt;] usb_kill_urb+0x8d/0xd0
 [&lt;ffffffff8111e5e0&gt;] ? wake_up_atomic_t+0x30/0x30
 [&lt;ffffffff817dafbe&gt;] usb_start_wait_urb+0xbe/0x150
 [&lt;ffffffff817db10c&gt;] usb_control_msg+0xbc/0xf0
 [&lt;ffffffff817d07de&gt;] hub_port_init+0x51e/0xb70
 [&lt;ffffffff817d4697&gt;] hub_event+0x817/0x1570
 [&lt;ffffffff810f3e6f&gt;] process_one_work+0x1ff/0x620
 [&lt;ffffffff810f3dcf&gt;] ? process_one_work+0x15f/0x620
 [&lt;ffffffff810f4684&gt;] worker_thread+0x64/0x4b0
 [&lt;ffffffff810f4620&gt;] ? rescuer_thread+0x390/0x390
 [&lt;ffffffff810fa7f5&gt;] kthread+0x105/0x120
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200
 [&lt;ffffffff81ba183f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [&lt;ffffffff817fd36d&gt;] xhci_setup_device+0x53d/0xa40
 [&lt;ffffffff817fd87e&gt;] xhci_address_device+0xe/0x10
 [&lt;ffffffff817d047f&gt;] hub_port_init+0x1bf/0xb70
 [&lt;ffffffff811247ed&gt;] ? trace_hardirqs_on+0xd/0x10
 [&lt;ffffffff817d4697&gt;] hub_event+0x817/0x1570
 [&lt;ffffffff810f3e6f&gt;] process_one_work+0x1ff/0x620
 [&lt;ffffffff810f3dcf&gt;] ? process_one_work+0x15f/0x620
 [&lt;ffffffff810f4684&gt;] worker_thread+0x64/0x4b0
 [&lt;ffffffff810f4620&gt;] ? rescuer_thread+0x390/0x390
 [&lt;ffffffff810fa7f5&gt;] kthread+0x105/0x120
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200
 [&lt;ffffffff81ba183f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
    usb_internal_control_msg
     usb_start_wait_urb
      usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Acked-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 ]

The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [&lt;ffffffff81b9bab7&gt;] schedule+0x37/0x90
 [&lt;ffffffff817da7cd&gt;] usb_kill_urb+0x8d/0xd0
 [&lt;ffffffff8111e5e0&gt;] ? wake_up_atomic_t+0x30/0x30
 [&lt;ffffffff817dafbe&gt;] usb_start_wait_urb+0xbe/0x150
 [&lt;ffffffff817db10c&gt;] usb_control_msg+0xbc/0xf0
 [&lt;ffffffff817d07de&gt;] hub_port_init+0x51e/0xb70
 [&lt;ffffffff817d4697&gt;] hub_event+0x817/0x1570
 [&lt;ffffffff810f3e6f&gt;] process_one_work+0x1ff/0x620
 [&lt;ffffffff810f3dcf&gt;] ? process_one_work+0x15f/0x620
 [&lt;ffffffff810f4684&gt;] worker_thread+0x64/0x4b0
 [&lt;ffffffff810f4620&gt;] ? rescuer_thread+0x390/0x390
 [&lt;ffffffff810fa7f5&gt;] kthread+0x105/0x120
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200
 [&lt;ffffffff81ba183f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [&lt;ffffffff817fd36d&gt;] xhci_setup_device+0x53d/0xa40
 [&lt;ffffffff817fd87e&gt;] xhci_address_device+0xe/0x10
 [&lt;ffffffff817d047f&gt;] hub_port_init+0x1bf/0xb70
 [&lt;ffffffff811247ed&gt;] ? trace_hardirqs_on+0xd/0x10
 [&lt;ffffffff817d4697&gt;] hub_event+0x817/0x1570
 [&lt;ffffffff810f3e6f&gt;] process_one_work+0x1ff/0x620
 [&lt;ffffffff810f3dcf&gt;] ? process_one_work+0x15f/0x620
 [&lt;ffffffff810f4684&gt;] worker_thread+0x64/0x4b0
 [&lt;ffffffff810f4620&gt;] ? rescuer_thread+0x390/0x390
 [&lt;ffffffff810fa7f5&gt;] kthread+0x105/0x120
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200
 [&lt;ffffffff81ba183f&gt;] ret_from_fork+0x3f/0x70
 [&lt;ffffffff810fa6f0&gt;] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
    usb_internal_control_msg
     usb_start_wait_urb
      usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge &lt;chris.bainbridge@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Acked-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>USB: add quirk for devices with broken LPM</title>
<updated>2016-01-22T17:24:44+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2015-12-10T20:27:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=782f17fde163a785e9bea86605aaab540f831bd8'/>
<id>782f17fde163a785e9bea86605aaab540f831bd8</id>
<content type='text'>
[ Upstream commit ad87e03213b552a5c33d5e1e7a19a73768397010 ]

Some USB device / host controller combinations seem to have problems
with Link Power Management.  For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.

This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Steinar H. Gunderson &lt;sgunderson@bigfoot.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ad87e03213b552a5c33d5e1e7a19a73768397010 ]

Some USB device / host controller combinations seem to have problems
with Link Power Management.  For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.

This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Steinar H. Gunderson &lt;sgunderson@bigfoot.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>usbnet: Fix tx_bytes statistic running backward in cdc_ncm</title>
<updated>2015-04-27T21:13:42+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben.hutchings@codethink.co.uk</email>
</author>
<published>2015-03-25T20:41:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e083cde25c210e1960a3fbfe71c9ada4f9148a26'/>
<id>e083cde25c210e1960a3fbfe71c9ada4f9148a26</id>
<content type='text'>
[ Upstream commit 7a1e890e2168e33fb62d84528e996b8b4b478fea ]

cdc_ncm disagrees with usbnet about how much framing overhead should
be counted in the tx_bytes statistics, and tries 'fix' this by
decrementing tx_bytes on the transmit path.  But statistics must never
be decremented except due to roll-over; this will thoroughly confuse
user-space.  Also, tx_bytes is only incremented by usbnet in the
completion path.

Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a
tx_bytes delta along with the tx_packets count.

Fixes: beeecd42c3b4 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics")
Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 7a1e890e2168e33fb62d84528e996b8b4b478fea ]

cdc_ncm disagrees with usbnet about how much framing overhead should
be counted in the tx_bytes statistics, and tries 'fix' this by
decrementing tx_bytes on the transmit path.  But statistics must never
be decremented except due to roll-over; this will thoroughly confuse
user-space.  Also, tx_bytes is only incremented by usbnet in the
completion path.

Fix this by requiring drivers that set FLAG_MULTI_FRAME to set a
tx_bytes delta along with the tx_packets count.

Fixes: beeecd42c3b4 ("net: cdc_ncm/cdc_mbim: adding NCM protocol statistics")
Signed-off-by: Ben Hutchings &lt;ben.hutchings@codethink.co.uk&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
