On Mon, 30 Nov 2015, Alan Cooper wrote: > I'm seeing a problem that looks like an issue in the USB-Persist > feature. I'm finding that all my 3.0 thumb drives are torn down and > brought back up (fail USB-Persist) during resume from "suspend to > memory" if they are plugged into a 2.0 EHCI/OHCI only port on my > embedded system. This embedded system seems to be unusual because it > removes VBUS during the suspend, but it looks like USB-Persist was > written to handle this and normal 2.0 thumb drives work correctly. > What I find is that the 3.0 thumb drives take 200ms-500ms after Port > Power is applied to set the "Current Connection Status" bit in the > PORTSC register and this causes check_port_resume_type() in hub.c to > return ENODEV. My 2.0 thumb drives show CONNECTED in < 100ms and this > works because hub_power_on() in hub.c waits 100ms for the power to > become stable. It looks to me like check_port_resume_type() should > look for the CONNECTED bit for hundreds of ms. I checked my Dell > laptop to see why it wasn't having a problem with the 3.0 thumb drives > and found that pm-suspend leaves the port power on and pm-hibernate > re-enables the port power in the BIOS which gives much more than a > 500ms delay before the kernel resume code checks for CONNECTED. > > 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. On the other hand, I don't have any better ideas. 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
