The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108:
Linux 3.18-rc4 (2014-11-09 14:55:29 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.18-rc7
for you to fetch changes up to 263e80b43559a6103e178a9176938ce171b23872:
usb-quirks: Add reset-resume quirk for MS Wireless Laser Mouse 6000 (2014-11-24 17:01:55 -0800)
----------------------------------------------------------------
USB fixes for 3.18-rc7
Here are some USB driver fixes and new device ids for 3.18-rc7.
Full details are in the shortlog, and all of these have been in the
linux-next tree for a while.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
----------------------------------------------------------------
Felipe Balbi (1):
usb: dwc3: ep0: fix for dead code
Greg Kroah-Hartman (2):
Merge tag 'fixes-for-v3.18-rc5' of git://git.kernel.org/.../balbi/usb into usb-linus
Merge tag 'usb-serial-3.18-rc6' of git://git.kernel.org/.../johan/usb-serial into usb-linus
Hans de Goede (2):
USB: uas: Add no-uas quirk for Hitachi usb-3 enclosures 4971:1012
usb-quirks: Add reset-resume quirk for MS Wireless Laser Mouse 6000
Johan Hovold (3):
USB: keyspan: fix tty line-status reporting
USB: keyspan: fix overrun-error reporting
USB: ssu100: fix overrun-error reporting
Lu Baolu (2):
Revert "xhci: clear root port wake on bits if controller isn't wake-up capable"
usb: xhci: rework root port wake bits if controller isn't allowed to wakeup
Mathias Nyman (2):
USB: xhci: don't start a halted endpoint before its new dequeue is set
USB: xhci: Reset a halted endpoint immediately when we encounter a stall.
Preston Fick (1):
USB: serial: cp210x: add IDs for CEL MeshConnect USB Stick
Troy Clark (1):
usb: serial: ftdi_sio: add PIDs for Matrix Orbital products
drivers/usb/core/quirks.c | 3 ++
drivers/usb/dwc3/ep0.c | 8 +--
drivers/usb/host/xhci-hub.c | 5 +-
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +++-
drivers/usb/host/xhci-ring.c | 43 ++++-----------
drivers/usb/host/xhci.c | 107 ++++++++++++++++++++------------------
drivers/usb/host/xhci.h | 2 +-
drivers/usb/serial/cp210x.c | 1 +
drivers/usb/serial/ftdi_sio.c | 33 ++++++++++++
drivers/usb/serial/ftdi_sio_ids.h | 39 ++++++++++++--
drivers/usb/serial/keyspan.c | 97 ++++++++++++++++++++--------------
drivers/usb/serial/ssu100.c | 11 ++--
drivers/usb/storage/unusual_uas.h | 7 +++
14 files changed, 224 insertions(+), 144 deletions(-)
Hmm, Greg.
I seem to get this problem possibly more commonly at boot these days:
usb 1-6: new full-speed USB device number 2 using xhci_hcd
usb 1-6: device descriptor read/64, error -71
xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
usb 1-6: hub failed to enable device, error -22
usb 1-6: new full-speed USB device number 3 using xhci_hcd
usb 1-6: device descriptor read/64, error -71
usb 1-6: hub failed to enable device, error -22
usb 1-6: new full-speed USB device number 4 using xhci_hcd
usb 1-6: Device not responding to setup address.
usb 1-6: Device not responding to setup address.
usb 1-6: device not accepting address 4, error -71
usb 1-6: new full-speed USB device number 5 using xhci_hcd
usb 1-6: Device not responding to setup address.
usb 1-6: Device not responding to setup address.
usb 1-6: device not accepting address 5, error -71
usb usb1-port6: unable to enumerate USB device
and my keyboard doesn't work. I then unplug and re-plug it, and get
usb 1-6: new full-speed USB device number 9 using xhci_hcd
usb 1-6: New USB device found, idVendor=2516, idProduct=0020
usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-6: Product: Quickfire Rapid i
usb 1-6: Manufacturer: CM Storm
Any ideas? Some setup delay that isn't long enough at boot time for a
slightly finicky device? It has happened before, but now I've gotten
it twice within a couple of days:
Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
(I've had this keyboard since mid-September, and looking at the logs
this machine has been rebooted 41 times since, with those three
failures..)
Linus
Linus Torvalds wrote:
> I seem to get this problem possibly more commonly at boot these days:
> usb 1-6: device descriptor read/64, error -71
> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
> usb 1-6: hub failed to enable device, error -22
Since my upgrade to 98e8d2e0 from something a bit older I also get
-71 error messages on boot and on resume, however this is older
hardware with only ehci-pci.
In my case some of the descriptors coming back from the device are bogus
when the device is first seen. The device then disconnects, and when it
is seen again by the kernel, nearly one second later, the descriptors
are fine and there are no errors. vid/pid change from hardware ODM to
OEM, suggesting that my device simply isn't ready when Linux first
talks with it.
//Peter
On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote:
> Hmm, Greg.
>
> I seem to get this problem possibly more commonly at boot these days:
>
> usb 1-6: new full-speed USB device number 2 using xhci_hcd
> usb 1-6: device descriptor read/64, error -71
> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
> usb 1-6: hub failed to enable device, error -22
> usb 1-6: new full-speed USB device number 3 using xhci_hcd
> usb 1-6: device descriptor read/64, error -71
> usb 1-6: hub failed to enable device, error -22
> usb 1-6: new full-speed USB device number 4 using xhci_hcd
> usb 1-6: Device not responding to setup address.
> usb 1-6: Device not responding to setup address.
> usb 1-6: device not accepting address 4, error -71
> usb 1-6: new full-speed USB device number 5 using xhci_hcd
> usb 1-6: Device not responding to setup address.
> usb 1-6: Device not responding to setup address.
> usb 1-6: device not accepting address 5, error -71
> usb usb1-port6: unable to enumerate USB device
>
> and my keyboard doesn't work. I then unplug and re-plug it, and get
>
> usb 1-6: new full-speed USB device number 9 using xhci_hcd
> usb 1-6: New USB device found, idVendor=2516, idProduct=0020
> usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 1-6: Product: Quickfire Rapid i
> usb 1-6: Manufacturer: CM Storm
>
> Any ideas? Some setup delay that isn't long enough at boot time for a
> slightly finicky device? It has happened before, but now I've gotten
> it twice within a couple of days:
>
> Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
> Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
> Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>
> (I've had this keyboard since mid-September, and looking at the logs
> this machine has been rebooted 41 times since, with those three
> failures..)
I've been seeing this occasionally recently as well, but was blaming a
"bad" USB 3 hub I have here that I use, and the problem goes away with a
replug.
Mathias, any ideas what is going on here?
thanks,
greg k-h
>
> Linus
On 02.12.2014 20:18, Greg KH wrote:
> On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote:
>> Hmm, Greg.
>>
>> I seem to get this problem possibly more commonly at boot these days:
>>
>> usb 1-6: new full-speed USB device number 2 using xhci_hcd
>> usb 1-6: device descriptor read/64, error -71
>> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
>> usb 1-6: hub failed to enable device, error -22
>> usb 1-6: new full-speed USB device number 3 using xhci_hcd
>> usb 1-6: device descriptor read/64, error -71
>> usb 1-6: hub failed to enable device, error -22
>> usb 1-6: new full-speed USB device number 4 using xhci_hcd
>> usb 1-6: Device not responding to setup address.
>> usb 1-6: Device not responding to setup address.
>> usb 1-6: device not accepting address 4, error -71
>> usb 1-6: new full-speed USB device number 5 using xhci_hcd
>> usb 1-6: Device not responding to setup address.
>> usb 1-6: Device not responding to setup address.
>> usb 1-6: device not accepting address 5, error -71
>> usb usb1-port6: unable to enumerate USB device
>>
>> and my keyboard doesn't work. I then unplug and re-plug it, and get
>>
>> usb 1-6: new full-speed USB device number 9 using xhci_hcd
>> usb 1-6: New USB device found, idVendor=2516, idProduct=0020
>> usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>> usb 1-6: Product: Quickfire Rapid i
>> usb 1-6: Manufacturer: CM Storm
>>
>> Any ideas? Some setup delay that isn't long enough at boot time for a
>> slightly finicky device? It has happened before, but now I've gotten
>> it twice within a couple of days:
>>
>> Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>> Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>> Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>>
>> (I've had this keyboard since mid-September, and looking at the logs
>> this machine has been rebooted 41 times since, with those three
>> failures..)
>
> I've been seeing this occasionally recently as well, but was blaming a
> "bad" USB 3 hub I have here that I use, and the problem goes away with a
> replug.
>
> Mathias, any ideas what is going on here?
>
Looks like when xhci changed to use "new scheme" device enumeration for non
SuperSpeed devices, we broke the device descriptor read retry for xhci.
Normally we try to read the descriptor again, and if it still fails then fall back
to old scheme. In this failing xhci case the slot is left in a default state after
first failed descriptor read, and we then try to enable the slot again in retry,
which is an invalid xhci context state change, and prints the error message:
xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1
After this It might be hard to get the device addressed.
I don't know why it fail the first device descriptor read, but fixing the xhci part
should allow more real reties. I'll work on it.
The change to use xhci "new scheme" enumeration was done in 3.14 to support known
legacy devices requiring it. commit 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72
-Mathias
> greg k-h
>
>>
>> Linus
On Wed, Dec 03, 2014 at 06:02:08PM +0200, Mathias Nyman wrote:
> On 02.12.2014 20:18, Greg KH wrote:
> > On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote:
> >> Hmm, Greg.
> >>
> >> I seem to get this problem possibly more commonly at boot these days:
> >>
> >> usb 1-6: new full-speed USB device number 2 using xhci_hcd
> >> usb 1-6: device descriptor read/64, error -71
> >> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
> >> usb 1-6: hub failed to enable device, error -22
> >> usb 1-6: new full-speed USB device number 3 using xhci_hcd
> >> usb 1-6: device descriptor read/64, error -71
> >> usb 1-6: hub failed to enable device, error -22
> >> usb 1-6: new full-speed USB device number 4 using xhci_hcd
> >> usb 1-6: Device not responding to setup address.
> >> usb 1-6: Device not responding to setup address.
> >> usb 1-6: device not accepting address 4, error -71
> >> usb 1-6: new full-speed USB device number 5 using xhci_hcd
> >> usb 1-6: Device not responding to setup address.
> >> usb 1-6: Device not responding to setup address.
> >> usb 1-6: device not accepting address 5, error -71
> >> usb usb1-port6: unable to enumerate USB device
> >>
> >> and my keyboard doesn't work. I then unplug and re-plug it, and get
> >>
> >> usb 1-6: new full-speed USB device number 9 using xhci_hcd
> >> usb 1-6: New USB device found, idVendor=2516, idProduct=0020
> >> usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> >> usb 1-6: Product: Quickfire Rapid i
> >> usb 1-6: Manufacturer: CM Storm
> >>
> >> Any ideas? Some setup delay that isn't long enough at boot time for a
> >> slightly finicky device? It has happened before, but now I've gotten
> >> it twice within a couple of days:
> >>
> >> Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
> >> Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
> >> Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
> >>
> >> (I've had this keyboard since mid-September, and looking at the logs
> >> this machine has been rebooted 41 times since, with those three
> >> failures..)
> >
> > I've been seeing this occasionally recently as well, but was blaming a
> > "bad" USB 3 hub I have here that I use, and the problem goes away with a
> > replug.
> >
> > Mathias, any ideas what is going on here?
> >
>
> Looks like when xhci changed to use "new scheme" device enumeration for non
> SuperSpeed devices, we broke the device descriptor read retry for xhci.
>
> Normally we try to read the descriptor again, and if it still fails then fall back
> to old scheme. In this failing xhci case the slot is left in a default state after
> first failed descriptor read, and we then try to enable the slot again in retry,
> which is an invalid xhci context state change, and prints the error message:
>
> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1
I see this all the time on my MinnowboardMax. For slot 2 that is.
And on this machine, it does not boot from USB properly, I have to,
after the kernel comes up (which was read off of USB by UEFI just fine),
unplug and plug the storage device back in so that the boot process
continues.
Works that way for 2 different USB 3.0 storage devices.
> After this It might be hard to get the device addressed.
>
> I don't know why it fail the first device descriptor read, but fixing the xhci part
> should allow more real reties. I'll work on it.
>
> The change to use xhci "new scheme" enumeration was done in 3.14 to support known
> legacy devices requiring it. commit 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72
How can that break "non-legacy" devices?
thanks,
greg k-h
On 11.12.2014 20:47, Greg KH wrote:
> On Wed, Dec 03, 2014 at 06:02:08PM +0200, Mathias Nyman wrote:
>> On 02.12.2014 20:18, Greg KH wrote:
>>> On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote:
>>>> Hmm, Greg.
>>>>
>>>> I seem to get this problem possibly more commonly at boot these days:
>>>>
>>>> usb 1-6: new full-speed USB device number 2 using xhci_hcd
>>>> usb 1-6: device descriptor read/64, error -71
>>>> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
>>>> usb 1-6: hub failed to enable device, error -22
>>>> usb 1-6: new full-speed USB device number 3 using xhci_hcd
>>>> usb 1-6: device descriptor read/64, error -71
>>>> usb 1-6: hub failed to enable device, error -22
>>>> usb 1-6: new full-speed USB device number 4 using xhci_hcd
>>>> usb 1-6: Device not responding to setup address.
>>>> usb 1-6: Device not responding to setup address.
>>>> usb 1-6: device not accepting address 4, error -71
>>>> usb 1-6: new full-speed USB device number 5 using xhci_hcd
>>>> usb 1-6: Device not responding to setup address.
>>>> usb 1-6: Device not responding to setup address.
>>>> usb 1-6: device not accepting address 5, error -71
>>>> usb usb1-port6: unable to enumerate USB device
>>>>
>>>> and my keyboard doesn't work. I then unplug and re-plug it, and get
>>>>
>>>> usb 1-6: new full-speed USB device number 9 using xhci_hcd
>>>> usb 1-6: New USB device found, idVendor=2516, idProduct=0020
>>>> usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
>>>> usb 1-6: Product: Quickfire Rapid i
>>>> usb 1-6: Manufacturer: CM Storm
>>>>
>>>> Any ideas? Some setup delay that isn't long enough at boot time for a
>>>> slightly finicky device? It has happened before, but now I've gotten
>>>> it twice within a couple of days:
>>>>
>>>> Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>>>> Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>>>> Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71
>>>>
>>>> (I've had this keyboard since mid-September, and looking at the logs
>>>> this machine has been rebooted 41 times since, with those three
>>>> failures..)
>>>
>>> I've been seeing this occasionally recently as well, but was blaming a
>>> "bad" USB 3 hub I have here that I use, and the problem goes away with a
>>> replug.
>>>
>>> Mathias, any ideas what is going on here?
>>>
>>
>> Looks like when xhci changed to use "new scheme" device enumeration for non
>> SuperSpeed devices, we broke the device descriptor read retry for xhci.
>>
>> Normally we try to read the descriptor again, and if it still fails then fall back
>> to old scheme. In this failing xhci case the slot is left in a default state after
>> first failed descriptor read, and we then try to enable the slot again in retry,
>> which is an invalid xhci context state change, and prints the error message:
>>
>> xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1
>
> I see this all the time on my MinnowboardMax. For slot 2 that is.
>
> And on this machine, it does not boot from USB properly, I have to,
> after the kernel comes up (which was read off of USB by UEFI just fine),
> unplug and plug the storage device back in so that the boot process
> continues.
>
> Works that way for 2 different USB 3.0 storage devices.
>
I got a patch that should fix the xhci "Setup ERROR" part in a setup-error-fix branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git setup-error-fix
It's based on Gregs usb-next tree.
It doesn't solve why the first device descritor read fails.
>> After this It might be hard to get the device addressed.
>>
>> I don't know why it fail the first device descriptor read, but fixing the xhci part
>> should allow more real reties. I'll work on it.
>>
>> The change to use xhci "new scheme" enumeration was done in 3.14 to support known
>> legacy devices requiring it. commit 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72
>
> How can that break "non-legacy" devices?
It added a enable_device callback for all usb2 devices during enumeration, which
fails if called twice, or if the slot was already enabled in the xhci case.
Caused whole enumeration to be aborted.
-Mathias
Solves xhci error cases with debug messages:
xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
usb 1-6: hub failed to enable device, error -22
xhci will give a context state error if we try to set a slot in default
state to the same default state with a special address device command.
Turns out this happends in several cases:
- retry reading the device rescriptor in hub_port_init()
- usb_reset_device() is called for a slot in default state
- in resume path, usb_port_resume() calls hub_port_init()
The default state is usually reached from most states with a reset device
command without any context state errors, but using the address device
command with BSA bit set (block set address) only works from the enabled
state and will otherwise cause context error.
solve this by checking if we are already in the default state before issuing
a address device BSA=1 command.
Fixes: 48fc7dbd52c0 ("usb: xhci: change enumeration scheme to 'new scheme'")
Cc: <[email protected]> # v3.14+
Signed-off-by: Mathias Nyman <[email protected]>
---
drivers/usb/host/xhci.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5be1bff..7245163 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3803,6 +3803,15 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev,
return -EINVAL;
}
+ if (setup == SETUP_CONTEXT_ONLY) {
+ slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
+ if (GET_SLOT_STATE(le32_to_cpu(slot_ctx->dev_state)) ==
+ SLOT_STATE_DEFAULT) {
+ xhci_dbg(xhci, "Slot already in default state\n");
+ return 0;
+ }
+ }
+
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
if (!command)
return -ENOMEM;
--
1.8.3.2
> I got a patch that should fix the xhci "Setup ERROR" part in a setup-error-fix branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git setup-error-fix
>
> It's based on Gregs usb-next tree.
> It doesn't solve why the first device descritor read fails.
Did that get applied? I just saw these messages on ia64 on v4.0-rc7 (not seen
on any earlier v4.0-* snapshots).
usb 7-4: new high-speed USB device number 5 using ehci-pci
usb 7-4: device descriptor read/8, error -71
usb 7-4: device descriptor read/8, error -71
usb usb7-port4: unable to enumerate USB device
usb 2-2: new full-speed USB device number 2 using uhci_hcd
usb 2-2: device descriptor read/64, error -71
usb 2-2: device descriptor read/64, error -71
usb 2-2: new full-speed USB device number 3 using uhci_hcd
usb 2-2: device descriptor read/64, error -71
usb 2-2: device descriptor read/64, error -71
usb 2-2: new full-speed USB device number 4 using uhci_hcd
usb 2-2: device descriptor read/8, error -71
usb 2-2: device descriptor read/8, error -71
usb 2-2: new full-speed USB device number 5 using uhci_hcd
usb 2-2: device descriptor read/8, error -71
usb 2-2: device descriptor read/8, error -71
usb usb2-port2: unable to enumerate USB device
-Tony