On Fri, 29 Aug 2014, Peter Chen wrote: > Felipe & Alan, thanks for your comments for these patches, I think I may need > to list these issues again to make things clearer. > > The purpose of these patchsets are to fix two issues: > - Some udcs failures at USB-IF certification Back-Voltage test, it needs > the dp is not pulled up when the vbus is not there, usb 2.0 spec 7.2.1 > and 7.1.5 require it. > - Some function drivers (f_uvc, f_obex, and android functions later) do > not want to pull up dp at the udc_start, they want it on demand, like app > has run. > > So, we can't pull up dp unconditionally at udc-core, I proposal the strategy > for pulling up dp after below two conditions are satisfied [1]: > - If the udc is ready to pull up dp > - all functions at gadget driver want to pullup dp, it will pull up dp. > > The first condition depends on UDCs, Some UDCs(UDC-A) doesn't need to > clear software pull up(run/stop) bit after vbus has disconnected, > the possible reason may these kinds of UDC have hardware logic to disable > pullup at dp when the vbus is not there, then it can pass back-voltage test, > so for these kinds of UDCs, they are always ready to pull up dp. > But for other UDCs(UDC-B, like chipidea), it needs to clear pullup bit after > vbus has disconnected to pass back-voltage test, for these kinds of UDCs, they > are only ready to pull up dp when the vbus is there. > The second condition are the same for all UDCs, the function/gadget driver > determine it. > > The patchset[1] has implemented above idea, UDC-A is always ready to pull up > dp, it will set ready (connect) bit at the end of udc_start, and UDC-B will > be ready when the vbus is there.[2], and the dp control strategy is decided by > two conditions[3]. > > Alan concerns why the .connect API has **connect** argument, the reason > is we need to call it at vbus handler to disable pullup bit when the vbus > is not there. It is indeed strange we have **connect** argument at .connect, > but current .disconnect API does not call usb_gadget_disconnect, so we have > no way to pull down dp when the vbus is not there, that is the story > we have this patchset and discussion. > > What's the next step for me? First, change the API so that the disconnect API _does_ call usb_gadget_disconnect. Then change the gadget drivers so that they tell the UDC driver when to turn the pullup on or off. This should happen whenever a function is activated or deactivated or whenever a connect or disconnect occurs. (In theory the gadget driver does not need to tell the UDC driver to turn off the pullup when a disconnect occurs; the UDC driver will turn it off anyway. But the gadget driver still needs to know that there was a disconnect. Otherwise it might tell the UDC driver to turn on the pullup at a time when the device isn't connected.) 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