Issue Type: | Bug |
---|---|
Priority: | 4 - Normal |
Status: | Resolved |
Created at: | 2019-02-05T22:25:53.848Z |
Updated at: | 2019-02-12T01:46:02.323Z |
Created by: | Former user |
---|---|
Reported by: | Former user |
Assigned to: | Former user |
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2019-02-12T01:45:40.086Z)
2019-02-14 Liz Lemon (Release Date: 2019-02-14)
We've seen that there are some issues with our detection of USB 3.1 ports. There are a few different things that have come up:
This boils down to a disagreement between how 3.1 should be shown in the xHCI Supported Protocol Capability. While the xhci specification says it should be 0x01 in Table 155: xHCI Supported Protocols, we've found cases in the wild where the value 0x10 is being used on some AMD derived controllers. The value 0x10 isn't crazy as this is the BCD (binary coded decimal) version of the value that the USB 3.1 specification uses. As such, we need to look for both.
The latter problem is just a simple typo.
To test this I booted on two different systems which have USB 3.1 ports, one a Kaby Lake based NUC, the other a Coffee Lake based desktop. In both cases we now properly counted the USB 3.1 ports that were found. In addition, I booted this on a few USB 3.0 based systems and found that nothing out of whack was there. Finally, I worked with a community member to verify that on their AMD based system where the revision was reported the other way, as 10h, that we no longer generate warnings and properly find all of their USB ports.
illumos-joyent commit 687c392b16815890c7ea0bb7d2c60e26a2b128fc (branch master, by Robert Mustacchi)
OS-7561 xhci USB 3.1 minor version encoded differently across vendors
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Reviewed by: Jordan Hendricks <jordan.hendricks@joyent.com>
Approved by: Jordan Hendricks <jordan.hendricks@joyent.com>