On Thu, 8 Dec 2011, Peter Chen wrote: > > On Wed, 7 Dec 2011, Peter Chen wrote: > > > >> Yes, just like we do for speed, �we can add "status" at struct usb_gadget, > >> and create sys entry at udc-core.c. > >> The question is how many status are needed? > >> connected/reset/addressed/suspended/disconnected? > > > > See what I wrote above. > > > > Oh, I see, thanks. > > "Possible states would include: unconnected (i.e., no +5 V power), > connected, resetting, active, and suspended." > > Then, from what stage you think is "active", after port change INTR or > receive SET_ADDRESS? What I had in mind was this: When power is detected, we go from "unconnected" to "connected". Then when a reset occurs, we go to "resetting", after which we go to "active". We stay in "active" (apart from occasional "resetting" or "suspended") until power is lost. Alternatively, we could add an extra state along the lines you suggest: Rename "connected" to "powered", and after "resetting", go to the "default" state until Set-Address has been received, then go to "active". This would be slightly better, because it gives more information about the enumeration procedure. In theory, "active" could be replaced by "unconfigured" and "configured" -- but the configuration information is in the gadget driver, not the UDC driver, so this probably isn't feasible. Don't forget that some systems can also have a "charging" state, and OTG systems can have a "host" state. > The user may also would like to use this "status" to check where it is > if he/she finds enumeration fails. Maybe, but the state doesn't provide very much information about enumeration. Using usbmon on the host would be a better way to debug problems. 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
