[Bug 220491] usb_storage connected SD card disconnects/reconnects on resume from suspend

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220491

Mathias Nyman (mathias.nyman@linux.intel.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mathias.nyman@linux.intel.c
                   |                            |om

--- Comment #23 from Mathias Nyman (mathias.nyman@linux.intel.com) ---
Looks like main issue is that the device is disconnected during suspend/resume.

USB3 devices will try to train the link automatically after connect, and get it
up to a full enabled and running U0 state without driver interaction.

I see at least 3 different outcomes after device was re-connected during
suspend/resume

1. Device link training was attempted early in resume (or during suspend), but
before xHC host was really capable to di its part.xHC sets a CAS flag (cold
attach state) to tell xhci driver device needs to reset to get the link in
shape. CAS is xhci specific, not part of usb specification, so xhci driver
reports a "compliance mode" state to usb core instead.  This is the idd 341
state Alan talked about.  For som unknown reason I can't see the expected
"Connect status change" here.

2. link is successfully retrained during resume, link reaches U0/enabled 
state. We also see the "Connect Status Change" (CSC) set. This link state looks
exactly like a successful resume from U3, except for the CSC flag. It's
possible usb core assumes device is now successfully resumed into U0 configured
state even if it is in U0 Default state, and needs to be addressed and
configured before it can respond to most requests.

3. reset-resume races with link error (ss.Inactive state). If link goes to
ss.Inactive it can only be recovered by a (device) reset. In this race case
the link goes to ss.inactive at the same time a usb core resets the device.
- link goes to ss.inactive (xhci driver and usb core are not yet aware of this)
- usb core reset device as part of reset-resume path.
- xhci driver sees ss.Inactive error state before reset, sets a flag that
prevents transfers. logs show "Can't queue urb, port error, link inactive"
messages.
- device is reset and recovers, flags stays forever preventing transfers.
This needs to be fixes in xhci driver

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.