On Wed, 12 Dec 2012, Lan Tianyu wrote: > >> I tested a usb ssd which consumes about 1s to makes usb port status > >> enter into connect status after powering off and powering on the port. > >> So I set the tries 20 and the longest latency is larger than 2s. > >> The debounce routine only guarantees port status stable rather than > >> enter into connect status. > > > > Then a better solution would be to first wait (up to 2 seconds) for a > > connect status and then call the debounce routine. > But some devices don't need to wait 2s such long time, 200ms is enough > for them. So I try to check status everytime after debounce. If it's > connected, go away. You should test the connect status in a loop. Each time through the loop, if it's not connected wait another 20 or so. > >>> You need to store somewhere the fact that you made this call, so that > >>> you will know whether or not to make the corresponding > >>> pm_runtime_get_sync call in usb_port_resume. > >> You mean I should add a new flag to keep the > >> pm_runtime_put_sync/put(port_dev) being called paired, right? > >> How about "needs_resume"? > > > > What you need isn't a resume; it's pm_runtime_get_sync. > How about "needs_runtime_get"? Or maybe "did_runtime_put". Something like that. > >> Even the power is still on but the PORT_POWER feature has been cleared. > >> So there should be no event from port, right? > > > > "should be" -- but buggy hardware might send an event anyway. Also, > > many root hubs don't pay attention to the power feature. If this > > happens, you probably should handle the connect change properly. I > > don't see any point in ignoring it. > How to deal with these connect change event or how to identify whether > the connect change event is trigger by real power off or not? If you get a connect change immediately after turning off the port power, there's no way to know whether it was because the power is now off or because the device really disconnected. So the best you can do is turn on the busy_bits entry, turn off the power, clear the connect-change and enable-change statuses, and turn off the busy_bits entry. 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
