On 02/20/2014 07:26 PM, Felipe Balbi wrote: > Hi, > > On Thu, Feb 20, 2014 at 07:30:13AM +0100, Robert Baldyga wrote: >> This patch adds support for deferred gadget driver bind as a remedy >> for situation when UDC drivers and gadget drivers are builded into >> the kernel, and gadget driver is loaded as first. >> >> Till now, it that case gadget driver loading failed with "No such device" >> and gadget driver didn't start. >> >> Now gadget drivers are added to driver_list and binded later, when UDC >> drivers will register in udc-core. > > this can be dangerous. If you lsmod you'll still see g_ether loaded but > not bound to anything. If you're on a system where there really isn't a > gadget controller (and dummy isn't enabled) then you really want to > return -ENODEV. There is no way to check if UDC driver will be loaded. However, if UDC device will not appear, loaded gadget drivers will not bind, so it can not cause any problems. >> It needed to modify gadget drivers, because now gadget binding is performed >> asynchronously, and functions used during this process can not be marked >> as __init. For that this patch removes __init marking from every function >> which may be called after module init function return. > > you never return -EPROBE_DEFER anywhere, what am I missing ? It's because there is no need for -EPROBE_DEFER. Gadget drivers registered in udc-core are added to driver_list. When UDC hardware drivers will appear, they will be binded. This is what I named "deferred bind", and it has nothing to do with -EPROBE_DEFER. Best regards Robert Baldyga Samsung R&D Institute Poland -- 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
