Hi, On Tue, Oct 01, 2013 at 06:17:56AM +0200, Marek Vasut wrote: > 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. I'll aggree to that, let's defer this patch for a bit. -- balbi
Attachment:
signature.asc
Description: Digital signature
