https://bugzilla.kernel.org/show_bug.cgi?id=220491 Mathias Nyman (mathias.nyman@xxxxxxxxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathias.nyman@linux.intel.c | |om --- Comment #23 from Mathias Nyman (mathias.nyman@xxxxxxxxxxxxxxx) --- 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.
