Hi, This patch set introduces two functions usb_gadget_deactivate() and usb_gadget_activate(), designed to prevent udc-core from showing binded gadget to host until it will be ready to work. It also makes usb_function_deactivate()/activate() using these functions. So far gadget deactivation was made by calling usb_gadget_disconnect(), but since we have usb_gadget_connect() called after gadget->bind() (in udc_bind_to_driver()) this method doesn't provide expected result. Calling function usb_gadget_disconnect() before gadget connection doesn't prevent udc-core from connecting gadget to driver - usb_gadget_disconnect() call is ignored and gadget is connected regardless to it. This usually results with errors, for example because we binded gadget with 0 configurations. This patch set fixes this problem adding functions allowing to perform effective gadget deactivation from gadget->bind(). According to Felipe's suggestion, in v2 there is one new patch adding 'bind_deactivated' flag, which should be used by functions which want to be binded as deactivated (for example because they need to wait for userspace daemon). Functions using this flag have to call usb_function_activate() to tell composite core they are ready to work. I have also converted functions which are using deactivation feature to make them using 'bind_deactivated' flag. Patches are also attached to this patch set. I was considering removing usb_function_deactivate() function since we have this flag, but I see that some of USB functions use it not only in bind() but also e.g. when userspace daemon disconnects. This is also the reason why I haven't named this flag 'controls_pullup', because this name doesn't describe precisely what does it mean. We also need to consider what to do when deactivation fails (which can happen if our UDC driver doesn't support the pullup callback). So far, when usb_function_deactivate() was called in bind(), we have had ability to decide what to do, when it fails. Now we preform function deactivation before its bind(), and when deactivation fails we fail to add the function to gadget. Maybe we should to allow it to continue despite deactivation failure and inform function (somehow) about this situation. If only it makes any sense, because in this form it looks more complicated that it was, and moreover it actually doesn't add any new features. Best regards, Robert Baldyga Changelog: v2: - add 'bind_deactivated' flag v1: https://lkml.org/lkml/2015/4/7/92 Robert Baldyga (5): usb: gadget: add usb_gadget_activate/deactivate functions usb: composite: fix usb_function_activate/deactivate functions usb: composite: add bind_deactivated flag to usb_function usb: gadget: f_uvc: use bind_deactivated flag usb: gadget: f_obex: use bind_deactivated flag drivers/usb/gadget/composite.c | 10 +++- drivers/usb/gadget/function/f_obex.c | 19 +------ drivers/usb/gadget/function/f_uvc.c | 7 +-- include/linux/usb/composite.h | 2 + include/linux/usb/gadget.h | 100 ++++++++++++++++++++++++++++++++--- 5 files changed, 106 insertions(+), 32 deletions(-) -- 1.9.1 -- 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
