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? Thanks Al Cooper -- 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
