Don,
Would you please try to apply the four attached patches? Two are
already in Greg's tree for the next 2.6.37 push to Linus, and the last
two are new. I think this should fix the issue with your USB 3.0 ports
getting disabled, but I'm not sure it will fix the issue with your
particular USB 3.0 device.
If it doesn't work, send me the dmesg with CONFIG_USB_XHCI_HCD_DEBUGGING
turned on.
Sarah Sharp
On Tue, Nov 16, 2010 at 02:09:10PM -0800, Sarah Sharp wrote:
> Ok, I think I see what's happening in your log. It is a software
> problem.
>
> The important bit of information is that if a USB 3.0 device doesn't
> detect the SuperSpeed terminations, it will switch ports over to the
> high speed port. Once it's in High Speed mode, it will only go looking
> for SuperSpeed terminations during a device reset.
>
> The USB core is used to being able to disable ports, and then later
> notice a connect change on the disabled port. But if the USB core
> attempts to disable a USB 3.0 port, then the SuperSpeed terminations are
> turned off, and the device never connects as a SuperSpeed device, only
> as a High Speed device. And that's what happens with your device:
>
> I can tell it originally connected on port 1:
>
> xhci_hcd 0000:04:00.0: set port reset, actual port 1 status = 0x1311
>
> There's a couple of SCSI commands the device doesn't like during the PM
> sync of filesystems, and the device gets reset twice. But it comes back
> fine, so that's not the problem.
>
> There's a power loss during suspend (or the BIOS mucked with the xHCI
> host controller), and the xHCI host is re-initialized:
>
> usb usb6: root hub lost power or was reset
>
> At this point, the device has migrated from port 1 (a SuperSpeed port)
> to port 3 (a High Speed port):
>
> xhci_hcd 0000:04:00.0: get port status, actual port 0 status = 0x2a0
> xhci_hcd 0000:04:00.0: Get port status returned 0x100
> xhci_hcd 0000:04:00.0: get port status, actual port 1 status = 0x2a0
> xhci_hcd 0000:04:00.0: Get port status returned 0x100
> xhci_hcd 0000:04:00.0: get port status, actual port 2 status = 0x2a0
> xhci_hcd 0000:04:00.0: Get port status returned 0x100
> xhci_hcd 0000:04:00.0: get port status, actual port 3 status = 0x202e1
> xhci_hcd 0000:04:00.0: Get port status returned 0x10101
>
> The USB core is trying to do something sneaky and persist USB devices
> across suspend. But since the original port (port 1) reports a
> disconnect, it assumes the device isn't there and disables the port:
>
> xhci_hcd 0000:04:00.0: disable port, actual port 1 status = 0x2a0
>
> Only then do we get a device disconnect on port 1:
>
> xhci_hcd 0000:04:00.0: get port status, actual port 1 status = 0x280
> xhci_hcd 0000:04:00.0: Get port status returned 0x100
> usb 6-2: USB disconnect, address 3
>
> The USB core tries to enumerate the device as a High Speed device, but
> the device is unresponsive:
> usb 6-4: device descriptor read/8, error -61
>
> The end result is that the USB 3.0 terminations are permanently
> disabled, and the device is stuck at High Speed. That would be
> consistent with your observation that a system reboot is required to get
> the device to connect at SuperSpeed again. I'm not sure if simply
> unloading the xHCI driver and reloading it would help.
>
>
> The real fix for this is to separate the xHCI roothub into two hubs: a
> USB 3.0 hub and a USB 2.0 hub. This is how an external USB 3.0 hub
> looks like to the system (two separate devices). Then on resume, we can
> look at the USB 2.0 hub ports first, reset any of the ports that report
> a connection, and then deal with USB 3.0 devices that migrated over from
> High Speed to SuperSpeed.
>
> I've been working on that code, but it's about 700 lines of code right
> now, and I'm not done with it, so I don't know if it can make it into
> 2.6.37.
>
> The simple fix might be to have the xHCI secretly not allow the USB core
> to disable ports. That needs a couple of the patches from my roothub
> separation patchset, but it shouldn't be nearly as large. But I'm not
> sure it's going to fix your issue, since the device migrated over to
> High Speed. I think that means you'll get the device back at
> SuperSpeed, but file systems will not persist across suspend.
>
> I'll send you the simple patch in a few.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>From e4be412fde7ee95d06a092656e5f7053540d2c05 Mon Sep 17 00:00:00 2001
From: Andiry Xu <andiry.xu@xxxxxxx>
Date: Wed, 27 Oct 2010 16:44:52 +0800
Subject: [PATCH 1/4] xHCI: release spinlock when setup interrupt
Jiri Slaby reports spinlock is held while calling kmalloc(GFP_KERNEL)
and request_irq() in xhci_resume().
Release the spinlock when setup interrupt.
Reported-by: Jiri Slaby <jirislaby@xxxxxxxxx>
Signed-off-by: Andiry Xu <andiry.xu@xxxxxxx>
Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
---
drivers/usb/host/xhci.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5d7d4e9..7c8d70f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -714,6 +714,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
return retval;
}
+ spin_unlock_irq(&xhci->lock);
/* Re-setup MSI-X */
if (hcd->irq)
free_irq(hcd->irq, hcd);
@@ -736,6 +737,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
hcd->irq = pdev->irq;
}
+ spin_lock_irq(&xhci->lock);
/* step 4: set Run/Stop bit */
command = xhci_readl(xhci, &xhci->op_regs->command);
command |= CMD_RUN;
--
1.6.3.3
>From d5069db9200a21ea5cac80cd25b0ee4207072df5 Mon Sep 17 00:00:00 2001
From: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
Date: Fri, 12 Nov 2010 11:59:31 -0800
Subject: [PATCH 2/4] xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
Tested-by: Andiry Xu <andiry.xu@xxxxxxx>
---
drivers/usb/host/xhci.c | 71 ++++++++++++++++++++++++++++++++++++++++------
1 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 7c8d70f..06fca08 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -577,6 +577,65 @@ static void xhci_restore_registers(struct xhci_hcd *xhci)
xhci_write_64(xhci, xhci->s3.erst_base, &xhci->ir_set->erst_base);
}
+static void xhci_set_cmd_ring_deq(struct xhci_hcd *xhci)
+{
+ u64 val_64;
+
+ /* step 2: initialize command ring buffer */
+ val_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
+ val_64 = (val_64 & (u64) CMD_RING_RSVD_BITS) |
+ (xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
+ xhci->cmd_ring->dequeue) &
+ (u64) ~CMD_RING_RSVD_BITS) |
+ xhci->cmd_ring->cycle_state;
+ xhci_dbg(xhci, "// Setting command ring address to 0x%llx\n",
+ (long unsigned long) val_64);
+ xhci_write_64(xhci, val_64, &xhci->op_regs->cmd_ring);
+}
+
+/*
+ * The whole command ring must be cleared to zero when we suspend the host.
+ *
+ * The host doesn't save the command ring pointer in the suspend well, so we
+ * need to re-program it on resume. Unfortunately, the pointer must be 64-byte
+ * aligned, because of the reserved bits in the command ring dequeue pointer
+ * register. Therefore, we can't just set the dequeue pointer back in the
+ * middle of the ring (TRBs are 16-byte aligned).
+ */
+static void xhci_clear_command_ring(struct xhci_hcd *xhci)
+{
+ struct xhci_ring *ring;
+ struct xhci_segment *seg;
+
+ ring = xhci->cmd_ring;
+ seg = ring->deq_seg;
+ do {
+ memset(seg->trbs, 0, SEGMENT_SIZE);
+ seg = seg->next;
+ } while (seg != ring->deq_seg);
+
+ /* Reset the software enqueue and dequeue pointers */
+ ring->deq_seg = ring->first_seg;
+ ring->dequeue = ring->first_seg->trbs;
+ ring->enq_seg = ring->deq_seg;
+ ring->enqueue = ring->dequeue;
+
+ /*
+ * Ring is now zeroed, so the HW should look for change of ownership
+ * when the cycle bit is set to 1.
+ */
+ ring->cycle_state = 1;
+
+ /*
+ * Reset the hardware dequeue pointer.
+ * Yes, this will need to be re-written after resume, but we're paranoid
+ * and want to make sure the hardware doesn't access bogus memory
+ * because, say, the BIOS or an SMI started the host without changing
+ * the command ring pointers.
+ */
+ xhci_set_cmd_ring_deq(xhci);
+}
+
/*
* Stop HC (not bus-specific)
*
@@ -604,6 +663,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
spin_unlock_irq(&xhci->lock);
return -ETIMEDOUT;
}
+ xhci_clear_command_ring(xhci);
/* step 3: save registers */
xhci_save_registers(xhci);
@@ -635,7 +695,6 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
u32 command, temp = 0;
struct usb_hcd *hcd = xhci_to_hcd(xhci);
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
- u64 val_64;
int old_state, retval;
old_state = hcd->state;
@@ -648,15 +707,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
/* step 1: restore register */
xhci_restore_registers(xhci);
/* step 2: initialize command ring buffer */
- val_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
- val_64 = (val_64 & (u64) CMD_RING_RSVD_BITS) |
- (xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
- xhci->cmd_ring->dequeue) &
- (u64) ~CMD_RING_RSVD_BITS) |
- xhci->cmd_ring->cycle_state;
- xhci_dbg(xhci, "// Setting command ring address to 0x%llx\n",
- (long unsigned long) val_64);
- xhci_write_64(xhci, val_64, &xhci->op_regs->cmd_ring);
+ xhci_set_cmd_ring_deq(xhci);
/* step 3: restore state and start state*/
/* step 3: set CRS flag */
command = xhci_readl(xhci, &xhci->op_regs->command);
--
1.6.3.3
>From 50b0ab7131206209296a9e5f262a24c299e8b2b8 Mon Sep 17 00:00:00 2001
From: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
Date: Tue, 26 Oct 2010 16:47:13 -0700
Subject: [PATCH 3/4] xhci: Setup array of USB 2.0 and USB 3.0 ports.
An xHCI host controller contains USB 2.0 and USB 3.0 ports, which can
occur in any order in the PORTSC registers. We cannot read the port speed
bits in the PORTSC registers at init time to determine the port speed,
since those bits are only valid when a USB device is plugged into the
port.
Instead, we read the "Supported Protocol Capability" registers in the xHC
Extended Capabilities space. Those describe the protocol, port offset in
the PORTSC registers, and port count. We use those registers to create
two arrays of pointers to the PORTSC registers, one for USB 3.0 ports, and
another for USB 2.0 ports. A third array keeps track of the port protocol
major revision, and is indexed with the internal xHCI port number.
This will make it easy to keep track of the port types to handle the xHCI
driver faking two roothubs. The two arrays of pointers can be used to
index the port the USB core wants, and the third array can be used to map
xHC port status change event to the correct roothub that should process
that event.
Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
---
drivers/usb/host/xhci-mem.c | 164 +++++++++++++++++++++++++++++++++++++++++++
drivers/usb/host/xhci.h | 26 +++++++
2 files changed, 190 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 2027706..e446639 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1443,6 +1443,13 @@ void xhci_mem_cleanup(struct xhci_hcd *xhci)
xhci->dcbaa = NULL;
scratchpad_free(xhci);
+
+ xhci->num_usb2_ports = 0;
+ xhci->num_usb3_ports = 0;
+ kfree(xhci->usb2_ports);
+ kfree(xhci->usb3_ports);
+ kfree(xhci->port_array);
+
xhci->page_size = 0;
xhci->page_shift = 0;
xhci->bus_suspended = 0;
@@ -1627,6 +1634,161 @@ static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
&xhci->ir_set->erst_dequeue);
}
+static void xhci_add_in_port(struct xhci_hcd *xhci, unsigned int num_ports,
+ u32 __iomem *addr, u8 major_revision)
+{
+ u32 temp, port_offset, port_count;
+ int i;
+
+ if (major_revision > 0x03) {
+ xhci_warn(xhci, "Ignoring unknown port speed, "
+ "Ext Cap %p, revision = 0x%x\n",
+ addr, major_revision);
+ /* Ignoring port protocol we can't understand. FIXME */
+ return;
+ }
+
+ /* Port offset and count in the third dword, see section 7.2 */
+ temp = xhci_readl(xhci, addr + 2);
+ port_offset = XHCI_EXT_PORT_OFF(temp);
+ port_count = XHCI_EXT_PORT_COUNT(temp);
+ xhci_dbg(xhci, "Ext Cap %p, port offset = %u, "
+ "count = %u, revision = 0x%x\n",
+ addr, port_offset, port_count, major_revision);
+ /* Port count includes the current port offset */
+ if (port_offset == 0 || (port_offset + port_count - 1) > num_ports)
+ /* WTF? "Valid values are â1â to MaxPorts" */
+ return;
+ port_offset--;
+ for (i = port_offset; i < (port_offset + port_count); i++) {
+ /* Duplicate entry. Ignore the port if the revisions differ. */
+ if (xhci->port_array[i] != 0) {
+ xhci_warn(xhci, "Duplicate port entry, Ext Cap %p,"
+ " port %u\n", addr, i);
+ xhci_warn(xhci, "Port was marked as USB %u, "
+ "duplicated as USB %u\n",
+ xhci->port_array[i], major_revision);
+ /* Only adjust the roothub port counts if we haven't
+ * found a similar duplicate.
+ */
+ if (xhci->port_array[i] != major_revision &&
+ xhci->port_array[i] != (u8) -1) {
+ if (xhci->port_array[i] == 0x03)
+ xhci->num_usb3_ports--;
+ else
+ xhci->num_usb2_ports--;
+ xhci->port_array[i] = (u8) -1;
+ }
+ /* FIXME: Should we disable the port? */
+ }
+ xhci->port_array[i] = major_revision;
+ if (major_revision == 0x03)
+ xhci->num_usb3_ports++;
+ else
+ xhci->num_usb2_ports++;
+ }
+ /* FIXME: Should we disable ports not in the Extended Capabilities? */
+}
+
+/*
+ * Scan the Extended Capabilities for the "Supported Protocol Capabilities" that
+ * specify what speeds each port is supposed to be. We can't count on the port
+ * speed bits in the PORTSC register being correct until a device is connected,
+ * but we need to set up the two fake roothubs with the correct number of USB
+ * 3.0 and USB 2.0 ports at host controller initialization time.
+ */
+static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)
+{
+ u32 __iomem *addr;
+ u32 offset;
+ unsigned int num_ports;
+ int i, port_index;
+
+ addr = &xhci->cap_regs->hcc_params;
+ offset = XHCI_HCC_EXT_CAPS(xhci_readl(xhci, addr));
+ if (offset == 0) {
+ xhci_err(xhci, "No Extended Capability registers, "
+ "unable to set up roothub.\n");
+ return -ENODEV;
+ }
+
+ num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
+ xhci->port_array = kzalloc(sizeof(*xhci->port_array)*num_ports, flags);
+ if (!xhci->port_array)
+ return -ENOMEM;
+
+ /*
+ * For whatever reason, the first capability offset is from the
+ * capability register base, not from the HCCPARAMS register.
+ * See section 5.3.6 for offset calculation.
+ */
+ addr = &xhci->cap_regs->hc_capbase + offset;
+ while (1) {
+ u32 cap_id;
+
+ cap_id = xhci_readl(xhci, addr);
+ if (XHCI_EXT_CAPS_ID(cap_id) == XHCI_EXT_CAPS_PROTOCOL)
+ xhci_add_in_port(xhci, num_ports, addr,
+ (u8) XHCI_EXT_PORT_MAJOR(cap_id));
+ offset = XHCI_EXT_CAPS_NEXT(cap_id);
+ if (!offset || (xhci->num_usb2_ports + xhci->num_usb3_ports)
+ == num_ports)
+ break;
+ /*
+ * Once you're into the Extended Capabilities, the offset is
+ * always relative to the register holding the offset.
+ */
+ addr += offset;
+ }
+
+ if (xhci->num_usb2_ports == 0 && xhci->num_usb3_ports == 0) {
+ xhci_warn(xhci, "No ports on the roothubs?\n");
+ return -ENODEV;
+ }
+ xhci_dbg(xhci, "Found %u USB 2.0 ports and %u USB 3.0 ports.\n",
+ xhci->num_usb2_ports, xhci->num_usb3_ports);
+ /*
+ * Note we could have all USB 3.0 ports, or all USB 2.0 ports.
+ * Not sure how the USB core will handle a hub with no ports...
+ */
+ if (xhci->num_usb2_ports) {
+ xhci->usb2_ports = kmalloc(sizeof(*xhci->usb2_ports)*
+ xhci->num_usb2_ports, flags);
+ if (!xhci->usb2_ports)
+ return -ENOMEM;
+
+ port_index = 0;
+ for (i = 0; i < num_ports; i++)
+ if (xhci->port_array[i] != 0x03) {
+ xhci->usb2_ports[port_index] =
+ &xhci->op_regs->port_status_base +
+ NUM_PORT_REGS*i;
+ xhci_dbg(xhci, "USB 2.0 port at index %u, "
+ "addr = %p\n", i,
+ xhci->usb2_ports[port_index]);
+ port_index++;
+ }
+ }
+ if (xhci->num_usb3_ports) {
+ xhci->usb3_ports = kmalloc(sizeof(*xhci->usb3_ports)*
+ xhci->num_usb3_ports, flags);
+ if (!xhci->usb3_ports)
+ return -ENOMEM;
+
+ port_index = 0;
+ for (i = 0; i < num_ports; i++)
+ if (xhci->port_array[i] == 0x03) {
+ xhci->usb3_ports[port_index] =
+ &xhci->op_regs->port_status_base +
+ NUM_PORT_REGS*i;
+ xhci_dbg(xhci, "USB 3.0 port at index %u, "
+ "addr = %p\n", i,
+ xhci->usb3_ports[port_index]);
+ port_index++;
+ }
+ }
+ return 0;
+}
int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
{
@@ -1809,6 +1971,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
if (scratchpad_alloc(xhci, flags))
goto fail;
+ if (xhci_setup_port_arrays(xhci, flags))
+ goto fail;
return 0;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 93d3bf4..e83edc2 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -454,6 +454,24 @@ struct xhci_doorbell_array {
/**
+ * struct xhci_protocol_caps
+ * @revision: major revision, minor revision, capability ID,
+ * and next capability pointer.
+ * @name_string: Four ASCII characters to say which spec this xHC
+ * follows, typically "USB ".
+ * @port_info: Port offset, count, and protocol-defined information.
+ */
+struct xhci_protocol_caps {
+ u32 revision;
+ u32 name_string;
+ u32 port_info;
+};
+
+#define XHCI_EXT_PORT_MAJOR(x) (((x) >> 24) & 0xff)
+#define XHCI_EXT_PORT_OFF(x) ((x) & 0xff)
+#define XHCI_EXT_PORT_COUNT(x) (((x) >> 8) & 0xff)
+
+/**
* struct xhci_container_ctx
* @type: Type of context. Used to calculated offsets to contained contexts.
* @size: Size of the context data
@@ -1235,6 +1253,14 @@ struct xhci_hcd {
u32 suspended_ports[8]; /* which ports are
suspended */
unsigned long resume_done[MAX_HC_PORTS];
+ /* Is each xHCI roothub port a USB 3.0, USB 2.0, or USB 1.1 port? */
+ u8 *port_array;
+ /* Array of pointers to USB 3.0 PORTSC registers */
+ u32 __iomem **usb3_ports;
+ unsigned int num_usb3_ports;
+ /* Array of pointers to USB 2.0 PORTSC registers */
+ u32 __iomem **usb2_ports;
+ unsigned int num_usb2_ports;
};
/* For testing purposes */
--
1.6.3.3
>From b1ea4ea4de33c20cacece208d340da128751849a Mon Sep 17 00:00:00 2001
From: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
Date: Tue, 16 Nov 2010 15:58:52 -0800
Subject: [PATCH 4/4] xhci: Don't let the USB core disable SuperSpeed ports.
Disabling SuperSpeed ports is a Very Bad Thing (TM). It disables
SuperSpeed terminations, which means that devices will never connect at
SuperSpeed on that port. For USB 2.0/1.1 ports, disabling the port meant
that the USB core could always get a connect status change later. That's
not true with USB 3.0 ports.
Do not let the USB core disable SuperSpeed ports. We can't rely on the
device speed in the port status registers, since that isn't valid until
there's a USB device connected to the port. Instead, we use the port
speed array that's created from the Extended Capabilities registers.
Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
---
drivers/usb/host/xhci-hub.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index fef5a1f..5d963e3 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -229,6 +229,13 @@ void xhci_ring_device(struct xhci_hcd *xhci, int slot_id)
static void xhci_disable_port(struct xhci_hcd *xhci, u16 wIndex,
u32 __iomem *addr, u32 port_status)
{
+ /* Don't allow the USB core to disable SuperSpeed ports. */
+ if (xhci->port_array[wIndex] == 0x03) {
+ xhci_dbg(xhci, "Ignoring request to disable "
+ "SuperSpeed port.\n");
+ return;
+ }
+
/* Write 1 to disable the port */
xhci_writel(xhci, port_status | PORT_PE, addr);
port_status = xhci_readl(xhci, addr);
--
1.6.3.3
