> > Since we introduce -EPROBE_DEFER for udc driver, it will be > > probed at late_initcall if it is defered. When the gadget > > is built in, it will return "couldn't find an available UDC" > > at such case. That's the problem we met at below link: > > > > http://marc.info/?l=linux-usb&m=137706435611447&w=2 > > > > We have no driver's probe at gadget driver, so we can't return > > -EPROBE_DEFER. And it is also not suitable to defer udc_bind_to_driver > > if the udc is not found temporarily, since it is hard to decide the > > return value for usb_gadget_probe_driver. > > > > Due to above reasons, mark gadget's init as late_initcall may be a > > moderate solution. > > > > Signed-off-by: Peter Chen <peter.chen@xxxxxxxxxxxxx> > > Seems this tries to paper over an issue with module dependencies , no? > In fact, there are module dependencies between udc and composite gadget. The udc must be created before composite gadget. If the creation of udc (or its controller driver) is deferred, the composite gadget driver has no way to know it, unless we change gadget framework a lot, eg add probe API for composite driver, create a thread to check udc creation if there is no udc, etc. -- 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
