On Tue, 1 Dec 2015, Alan Cooper wrote: > On Tue, Dec 1, 2015 at 11:07 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 1 Dec 2015, Oliver Neukum wrote: > > > >> On Tue, 2015-12-01 at 10:41 -0500, Alan Stern wrote: > >> > > A recent patch, 7fa40910e0bf5ef32eca49595d950cb24f6402bf, added a > >> > > CONNECTED retry for a different reason and I could simply increase > >> > > this retry time. Any thoughts? > >> > > >> > I don't know. You've got a non-compliant host combined with an > >> > excessively slow device. It seems unwise to penalize everybody by > >> > slowing down their resumes (by 500 ms!) just because of this one > >> > bad combination. > > I'm now sure the host in "non-compliant". It is non-compliant if it turns off Vbus power during suspend. But that may be caused by the platform more than by the controller itself. > It looks like the USB-persist feature > was created for the loss of "power session" on suspend/resume. That's exactly what it was created for. > Hibernate > will usually remove power and it's just because the BIOS re-enables VBUS > that PC's don't see this problem. Also there doesn't seem to be any spec for > how long after VBUS a 2.0 (or 3.0) device should become CONNECTED. There isn't. > Most 2.0 or 3.0 hard drive based devices, either using a SATA to USB dongle > or devices like the WD Passport take >500ms to set CONNECTED. I've tested > many different 3.0 devices plugged into a 2.0 only port and all of them take > longer than the 100ms currently needed to succeed. > I think the best solution would be to use "wait_for_ss_port_enable()" > (renamed) for 2.0 devices and not just 3.0 devices as discussed in: > http://marc.info/?l=linux-usb&m=143768271119144&w=2 Okay, go ahead and submit a patch. Alan Stern -- 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
