On Thu, 25 Aug 2011 01:04:19 +0200, Felipe Balbi <balbi@xxxxxx> wrote:
there's one catch. As of today, we always start UDCs with data pullups connected, which means that we could connect to a host even before a gadget driver is loaded. My point in moving to udc_start/udc_stop is that the above would be take care of. See udc-core.c: [...]
Honestly I'm not quite sure why udc_start/udc_stop is needed here. Even without those the UDC driver can start with all hw disabled and turn it on only after the gadget driver's bind callback finishes.
If all UDCs are converted to udc_start()/udc_stop() we get the guarantee that they will only conect to host after gadget driver is fully loaded for free.
We can also, finally, properly use the usb_function_deactivate/ usb_function_activate properly. So for each registered function, composite.c calls usb_function_deactivate() and function is _required_ to call usb_function_activate when it's ready.
I'm not really sure why that would be beneficial. Also, it would still require disconnect-connect cycle if some function decides to (de)activate itself while gadget is connected.
Then, when on gadget driver's bind() we can take this kind of speed decision and pass that on to UDC driver.
So can we leave things as they are for now and wait for UDCs to be converted
and once this is done, do all kinds of magic we want in copomiset's bind callback? -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz (o o) ooo +-----<email/xmpp: mnazarewicz@xxxxxxxxxx>-----ooO--(_)--Ooo-- -- 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
