On Wed, 13 Aug 2014, Paul Zimmerman wrote: > 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. (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.) 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
