<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/usb/core, branch linux-4.20.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-4.20.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-02-12T19:02:14+00:00</updated>
<entry>
<title>usb: hub: delay hub autosuspend if USB3 port is still link training</title>
<updated>2019-02-12T19:02:14+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2018-11-28T13:55:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2fe047eb0eceb4144240517737c6a0d8d721a71b'/>
<id>urn:sha1:2fe047eb0eceb4144240517737c6a0d8d721a71b</id>
<content type='text'>
[ Upstream commit e86108940e541febf35813402ff29fa6f4a9ac0b ]

When initializing a hub we want to give a USB3 port in link training
the same debounce delay time before autosuspening the hub as already
trained, connected enabled ports.

USB3 ports won't reach the enabled state with "current connect status" and
"connect status change" bits set until the USB3 link training finishes.

Catching the port in link training (polling) and adding the debounce delay
prevents unnecessary failed attempts to autosuspend the hub.

Signed-off-by: Mathias Nyman &lt;mathias.nyman@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;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>USB: leds: fix regression in usbport led trigger</title>
<updated>2019-01-31T07:15:35+00:00</updated>
<author>
<name>Christian Lamparter</name>
<email>chunkeey@gmail.com</email>
</author>
<published>2019-01-11T16:29:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f15b66e8c2d269f224a25ff5877c5a4bfbca7f7f'/>
<id>urn:sha1:f15b66e8c2d269f224a25ff5877c5a4bfbca7f7f</id>
<content type='text'>
commit 91f7d2e89868fcac0e750a28230fdb1ad4512137 upstream.

The patch "usb: simplify usbport trigger" together with "leds: triggers:
add device attribute support" caused an regression for the usbport
trigger. it will no longer enumerate any active usb hub ports under the
"ports" directory in the sysfs class directory, if the usb host drivers
are fully initialized before the usbport trigger was loaded.

The reason is that the usbport driver tries to register the sysfs
entries during the activate() callback. And this will fail with -2 /
ENOENT because the patch "leds: triggers: add device attribute support"
made it so that the sysfs "ports" group was only being added after the
activate() callback succeeded.

This version of the patch reverts parts of the "usb: simplify usbport
trigger" patch and restores usbport trigger's functionality.

Fixes: 6f7b0bad8839 ("usb: simplify usbport trigger")
Signed-off-by: Christian Lamparter &lt;chunkeey@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Acked-by: Jacek Anaszewski &lt;jacek.anaszewski@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: Add USB_QUIRK_DELAY_CTRL_MSG quirk for Corsair K70 RGB</title>
<updated>2019-01-16T21:03:23+00:00</updated>
<author>
<name>Jack Stocker</name>
<email>jackstocker.93@gmail.com</email>
</author>
<published>2019-01-03T21:56:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ef2da729fa7c08f1271194de61d9f863efd6c7e'/>
<id>urn:sha1:1ef2da729fa7c08f1271194de61d9f863efd6c7e</id>
<content type='text'>
commit 3483254b89438e60f719937376c5e0ce2bc46761 upstream.

To match the Corsair Strafe RGB, the Corsair K70 RGB also requires
USB_QUIRK_DELAY_CTRL_MSG to completely resolve boot connection issues
discussed here: https://github.com/ckb-next/ckb-next/issues/42.
Otherwise roughly 1 in 10 boots the keyboard will fail to be detected.

Patch that applied delay control quirk for Corsair Strafe RGB:
cb88a0588717 ("usb: quirks: add control message delay for 1b1c:1b20")

Previous K70 RGB patch to add delay-init quirk:
7a1646d92257 ("Add delay-init quirk for Corsair K70 RGB keyboards")

Signed-off-by: Jack Stocker &lt;jackstocker.93@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usbcore: Select only first configuration for non-UAC3 compliant devices</title>
<updated>2019-01-16T21:03:20+00:00</updated>
<author>
<name>Saranya Gopal</name>
<email>saranya.gopal@intel.com</email>
</author>
<published>2019-01-06T02:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5d8c09bacb99e1e7ae68f1d34473ee66fab00f34'/>
<id>urn:sha1:5d8c09bacb99e1e7ae68f1d34473ee66fab00f34</id>
<content type='text'>
commit ff2a8c532c14fd22fb26a36574d9ff199afbbe54 upstream.

In most of the UAC1 and UAC2 audio devices, the first
configuration is most often the best configuration.
However, with recent patch to support UAC3 configuration,
second configuration was unintentionally chosen for
some of the UAC1/2 devices that had more than one
configuration. This was because of the existing check
after the audio config check which selected any config
which had a non-vendor class. This patch fixes this issue.

Fixes: f13912d3f014 ("usbcore: Select UAC3 configuration for audio if present")
Reported-by: Con Kolivas &lt;kernel@kolivas.org&gt;
Signed-off-by: Saranya Gopal &lt;saranya.gopal@intel.com&gt;
Tested-by: Con Kolivas &lt;kernel@kolivas.org&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: check usb_get_extra_descriptor for proper size</title>
<updated>2018-12-05T20:20:14+00:00</updated>
<author>
<name>Mathias Payer</name>
<email>mathias.payer@nebelwelt.net</email>
</author>
<published>2018-12-05T20:19:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=704620afc70cf47abb9d6a1a57f3825d2bca49cf'/>
<id>urn:sha1:704620afc70cf47abb9d6a1a57f3825d2bca49cf</id>
<content type='text'>
When reading an extra descriptor, we need to properly check the minimum
and maximum size allowed, to prevent from invalid data being sent by a
device.

Reported-by: Hui Peng &lt;benquike@gmail.com&gt;
Reported-by: Mathias Payer &lt;mathias.payer@nebelwelt.net&gt;
Co-developed-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Hui Peng &lt;benquike@gmail.com&gt;
Signed-off-by: Mathias Payer &lt;mathias.payer@nebelwelt.net&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: quirk: add no-LPM quirk on SanDisk Ultra Flair device</title>
<updated>2018-12-05T09:37:29+00:00</updated>
<author>
<name>Harry Pan</name>
<email>harry.pan@intel.com</email>
</author>
<published>2018-11-28T16:40:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f2dde6ba89b1ef1fe23c1138131b315d9aa4019'/>
<id>urn:sha1:2f2dde6ba89b1ef1fe23c1138131b315d9aa4019</id>
<content type='text'>
Some lower volume SanDisk Ultra Flair in 16GB, which the VID:PID is
in 0781:5591, will aggressively request LPM of U1/U2 during runtime,
when using this thumb drive as the OS installation key we found the
device will generate failure during U1 exit path making it dropped
from the USB bus, this causes a corrupted installation in system at
the end.

i.e.,
[  166.918296] hub 2-0:1.0: state 7 ports 7 chg 0000 evt 0004
[  166.918327] usb usb2-port2: link state change
[  166.918337] usb usb2-port2: do warm reset
[  166.970039] usb usb2-port2: not warm reset yet, waiting 50ms
[  167.022040] usb usb2-port2: not warm reset yet, waiting 200ms
[  167.276043] usb usb2-port2: status 02c0, change 0041, 5.0 Gb/s
[  167.276050] usb 2-2: USB disconnect, device number 2
[  167.276058] usb 2-2: unregistering device
[  167.276060] usb 2-2: unregistering interface 2-2:1.0
[  167.276170] xhci_hcd 0000:00:15.0: shutdown urb ffffa3c7cc695cc0 ep1in-bulk
[  167.284055] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  167.284064] sd 0:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 33 04 90 00 01 00 00
...

Analyzed the USB trace in the link layer we realized it is because
of the 6-ms timer of tRecoveryConfigurationTimeout which documented
on the USB 3.2 Revision 1.0, the section 7.5.10.4.2 of "Exit from
Recovery.Configuration"; device initiates U1 exit -&gt; Recovery.Active
-&gt; Recovery.Configuration, then the host timer timeout makes the link
transits to eSS.Inactive -&gt; Rx.Detect follows by a Warm Reset.

Interestingly, the other higher volume of SanDisk Ultra Flair sharing
the same VID:PID, such as 64GB, would not request LPM during runtime,
it sticks at U0 always, thus disabling LPM does not affect those thumb
drives at all.

The same odd occures in SanDisk Ultra Fit 16GB, VID:PID in 0781:5583.

Signed-off-by: Harry Pan &lt;harry.pan@intel.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: Fix invalid-free bug in port_over_current_notify()</title>
<updated>2018-12-05T09:37:29+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2018-11-28T16:25:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d81bb019d7bb30091e3c796102c00935d6dd7ca9'/>
<id>urn:sha1:d81bb019d7bb30091e3c796102c00935d6dd7ca9</id>
<content type='text'>
Syzbot and KASAN found the following invalid-free bug in
port_over_current_notify():

--------------------------------------------------------------------------
BUG: KASAN: double-free or invalid-free in port_over_current_notify
drivers/usb/core/hub.c:5192 [inline]
BUG: KASAN: double-free or invalid-free in port_event
drivers/usb/core/hub.c:5241 [inline]
BUG: KASAN: double-free or invalid-free in hub_event+0xd97/0x4140
drivers/usb/core/hub.c:5384

CPU: 1 PID: 32710 Comm: kworker/1:3 Not tainted 4.20.0-rc3+ #129
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x244/0x39d lib/dump_stack.c:113
  print_address_description.cold.7+0x9/0x1ff mm/kasan/report.c:256
  kasan_report_invalid_free+0x64/0xa0 mm/kasan/report.c:336
  __kasan_slab_free+0x13a/0x150 mm/kasan/kasan.c:501
  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
  __cache_free mm/slab.c:3498 [inline]
  kfree+0xcf/0x230 mm/slab.c:3817
  port_over_current_notify drivers/usb/core/hub.c:5192 [inline]
  port_event drivers/usb/core/hub.c:5241 [inline]
  hub_event+0xd97/0x4140 drivers/usb/core/hub.c:5384
  process_one_work+0xc90/0x1c40 kernel/workqueue.c:2153
  worker_thread+0x17f/0x1390 kernel/workqueue.c:2296
  kthread+0x35a/0x440 kernel/kthread.c:246
  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
--------------------------------------------------------------------------

The problem is caused by use of a static array to store
environment-string pointers.  When the routine is called by multiple
threads concurrently, the pointers from one thread can overwrite those
from another.

The solution is to use an ordinary automatic array instead of a static
array.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: syzbot+98881958e1410ec7e53c@syzkaller.appspotmail.com
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series</title>
<updated>2018-11-26T07:09:47+00:00</updated>
<author>
<name>Michael Niewöhner</name>
<email>linux@mniewoehner.de</email>
</author>
<published>2018-11-25T16:57:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=effd14f66cc1ef6701a19c5a56e39c35f4d395a5'/>
<id>urn:sha1:effd14f66cc1ef6701a19c5a56e39c35f4d395a5</id>
<content type='text'>
Cherry G230 Stream 2.0 (G85-231) and 3.0 (G85-232) need this quirk to
function correctly. This fixes a but where double pressing numlock locks
up the device completely with need to replug the keyboard.

Signed-off-by: Michael Niewöhner &lt;linux@mniewoehner.de&gt;
Tested-by: Michael Niewöhner &lt;linux@mniewoehner.de&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: core: Fix hub port connection events lost</title>
<updated>2018-11-14T22:28:26+00:00</updated>
<author>
<name>Dennis Wassenberg</name>
<email>dennis.wassenberg@secunet.com</email>
</author>
<published>2018-11-13T13:40:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=22454b79e6de05fa61a2a72d00d2eed798abbb75'/>
<id>urn:sha1:22454b79e6de05fa61a2a72d00d2eed798abbb75</id>
<content type='text'>
This will clear the USB_PORT_FEAT_C_CONNECTION bit in case of a hub port reset
only if a device is was attached to the hub port before resetting the hub port.

Using a Lenovo T480s attached to the ultra dock it was not possible to detect
some usb-c devices at the dock usb-c ports because the hub_port_reset code
will clear the USB_PORT_FEAT_C_CONNECTION bit after the actual hub port reset.
Using this device combo the USB_PORT_FEAT_C_CONNECTION bit was set between the
actual hub port reset and the clear of the USB_PORT_FEAT_C_CONNECTION bit.
This ends up with clearing the USB_PORT_FEAT_C_CONNECTION bit after the
new device was attached such that it was not detected.

This patch will not clear the USB_PORT_FEAT_C_CONNECTION bit if there is
currently no device attached to the port before the hub port reset.
This will avoid clearing the connection bit for new attached devices.

Signed-off-by: Dennis Wassenberg &lt;dennis.wassenberg@secunet.com&gt;
Acked-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: quirks: Add no-lpm quirk for Raydium touchscreens</title>
<updated>2018-11-07T12:23:18+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2018-10-26T05:33:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=deefd24228a172d1b27d4a9adbfd2cdacd60ae64'/>
<id>urn:sha1:deefd24228a172d1b27d4a9adbfd2cdacd60ae64</id>
<content type='text'>
Raydium USB touchscreen fails to set config if LPM is enabled:
[    2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119
[    2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.030660] usb 1-8: Product: Raydium Touch System
[    2.030661] usb 1-8: Manufacturer: Raydium Corporation
[    7.132209] usb 1-8: can't set config #1, error -110

Same behavior can be observed on 2386:3114.

Raydium claims the touchscreen supports LPM under Windows, so I used
Microsoft USB Test Tools (MUTT) [1] to check its LPM status. MUTT shows
that the LPM doesn't work under Windows, either. So let's just disable LPM
for Raydium touchscreens.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-test-tools

Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
