> > > This thread seems to have wandered pretty far off-topic. I just wanted > > to make the point that if you create another API function for this > > issue, please be aware that not all controllers/phys will need it or > > be able to support it. In fact, I think this issue is specific to the > > chipidea core, so maybe it just needs a quirk or something? > > I don't think any special treatment will be needed. If a controller/PHY > combination is unable to detect Vbus changes in software then it simply > won't invoke the callback. Things will still work correctly provided the > hardware disables the pullup whenever Vbus is off. All the UDC driver > will need to do is invoke the gadget driver's connect callback once at > the start, and it must be doing that already. > > Peter simply has to do is fix up composite.c and udc-core.c. > udc_bind_to_driver() shouldn't call usb_gadget_connect() automatically, > and composite_driver_template needs to have a .connect callback. Then > composite.c can enable or disable the pullup at appropriate times, based > on function activations and the current connection status. > Thanks, Alan. I will have a patchset for this issue. > (I'm not sure how well this will work with the soft_connect sysfs > attribute in udc-core, though. And that attribute doesn't seem to be > mentioned anywhere under Documentation/ABI.) > I think it may be used to disable gadget function at runtime, Felipe may know it well. Peter -- 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
