On Tue, Dec 1, 2015 at 12:12 PM, Alan Cooper <alcooperx@xxxxxxxxx> 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 looks like the USB-persist feature > was created for the loss of "power session" on suspend/resume. 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. > 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. > >>> > >>> > On the other hand, I don't have any better ideas. >>> >>> Yet another quirk. Assume this to be necessary only if the port >>> was connected to a quirky device before loss of power. >> >> Yeah, okay. Although we have no way to know that the non-compliant >> host controller turned off the port power. >> >> Alan, can you provide the vendor and product IDs for your USB-3 flash >> drive? Or would you prefer to write a patch yourself? > > 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 I forgot to say that I'll submit the patch if this seems reasonable. I thought it might also be useful to add a sysfs entry that could extend the timeout. I have a Lexar 3.0 device that takes 6 seconds to become connected in either a 3.0 or 2.0 port. Al -- 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
