On Mon, Jul 27, 2009 at 11:01:20PM +0200, ext David Brownell wrote: > On Monday 27 July 2009, Felipe Balbi wrote: > > musb was enabling softconnect flag only after gadget driver's > > bind() was beeing called, > > In mainline I see that flag *set* (to the default, "device is > ready to respond after binding _unless_ it says otherwise") > just before the spin_lock_irqsave() at the beginning of this > patch ... i.e. *before* gadget binding. > > > > meaning that if a gadget driver > > was calling usb_function_deactivate, we would never be able > > to defer gadget enumeration until usb_function_activate was > > called. > > I'd have thought the issue was entirely different. See this > comment right in the middle of the block of code you were > working with (moving bind from beginning to end of block): > > /* FIXME this ignores the softconnect flag. Drivers are > * allowed hold the peripheral inactive until for example > * userspace hooks up printer hardware or DSP codecs, so > * hosts only see fully functional devices. > */ > > In short, making that mechanism work with this driver will > involve first coding it, then debugging it. Notice how the > musb_gadget_vbus_session() mechanism isn't enabled, and how > it's just stubbed in as another big FIXME... > > So, NAK on this too. see that when you enable otg musb_start() is called *afterwards* which sets softconnect flag again. -- balbi -- 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
