Dear Chen Peter-B29397, > > > 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. I do see the problem. I'm just worried this change is only pushing the inevitable problem away for a bit. I think a bit more discussion would be a good idea now and this patch is a good starter for that. Best regards, Marek Vasut -- 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
