[PATCH] xhci: Tell USB core both roothubs lost power.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Cai, will you try the following patch with Andiry's work-around patch,
but not with Alan's patch?

This solves the 2nd hibernate failure for me.  I think Alan's patch was
masking underlying issues when the USB 3.0 roothub was not marked as
having lost power.  The USB core really thought the USB 3.0 hard drive
was still there, which is why can_submit was set.  Alan, do you think
your patch is still needed?

With this patch (and not Alan's patch), I can successfully hibernate
multiple times.  Unfortunately, with the USB 3.0 hub I have, I see that
the USB 3.0 hard drive can't be enumerated after the resume.  The set
address command fails with a transfer error.  Turning on and off the
hard drive (it's externally powered) doesn't help.  Plugging it into
different ports on the USB 3.0 hub doesn't help.  Only unplugging the
USB 3.0 hub and replugging it in allows the USB 3.0 hard drive to be
enumerated.

Adding Andiry's work around patch doesn't seem to help the set address
issue, so I'm chalking that up to USB 3.0 hub wierdness.  I haven't
tested with his 5 larger patches yet.  At least the system can hibernate
now, even if the user needs to unplug/replug their USB 3.0 devices to
make them work.

Andiry, is your workaround patch needed to allow the system to suspend?
I can't test suspend on my box.

8<------------------------------------------------------------------->8

On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:

[  164.748310] usb usb1: root hub lost power or was reset
[  164.748353] usb usb2: root hub lost power or was reset
[  164.748487] usb usb3: root hub lost power or was reset
[  164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[  164.870039] hub 4-0:1.0: hub_resume
...
[  164.870054] hub 3-0:1.0: hub_reset_resume

This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active.  It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:

[  164.980044] hub 4-1:1.0: hub_resume
[  164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[  164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[  164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[  164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status  = 0x2e1
[  164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status  = 0x2a0
[  164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[  164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[  164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980094] hub 4-1:1.0: activate --> -22
[  164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[  164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[  164.980123] hub 4-1:1.0: can't resume port 4, status -22
[  164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[  164.980129] usb 4-1.4: can't resume, status -22
[  164.980131] hub 4-1:1.0: logical disconnect on port 4

This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:

[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb]  Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760

Make sure to inform the USB core that *both* xHCI roothubs lost power.

Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
---
 drivers/usb/host/xhci.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 196e018..23ecc32 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -771,7 +771,9 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 
 	/* If restore operation fails, re-initialize the HC during resume */
 	if ((temp & STS_SRE) || hibernated) {
-		usb_root_hub_lost_power(hcd->self.root_hub);
+		/* Let the USB core know _both_ roothubs lost power. */
+		usb_root_hub_lost_power(xhci->main_hcd->self.root_hub);
+		usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub);
 
 		xhci_dbg(xhci, "Stop HCD\n");
 		xhci_halt(xhci);
-- 
1.7.1

--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux