On 10/05/16 11:12, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq@xxxxxx> writes: >> On 10/05/16 06:14, Peter Chen wrote: >>> On Mon, May 09, 2016 at 12:45:38PM +0300, Roger Quadros wrote: >>>> On 06/05/16 12:41, Peter Chen wrote: >>>>> On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote: >>>>>> The OTG core will use struct otg_hcd_ops to interface >>>>>> with the HCD controller. >>>>>> >>>>>> The main purpose of this interface is to avoid directly >>>>>> calling HCD APIs from the OTG core as they >>>>>> wouldn't be defined in the built-in symbol table if >>>>>> CONFIG_USB is m. >>>>>> >>>>>> Signed-off-by: Roger Quadros <rogerq@xxxxxx> >>>>>> Acked-by: Peter Chen <peter.chen@xxxxxxx> >>>>> >>>>> Roger, after thinking more, I still think current dependency between >>>>> OTG, HCD and gadget are too complicated. Since the OTG can't work >>>>> if it is built as module, I suggest letting OTG depends on HCD && >>>>> USB_GADGET, and it is a boolean, in that case, we don't need to >>>>> export any HCD and gadget ops, things will be much simpler. >>>>> What's your opinion? >>>> >>>> How will it work if HCD and USB_GADGET are modules and OTG is built-in? >>>> >>> >>> The OTG will not be compiled at this situation, since it is boolean. >>> In fact, like I mentioned at above, OTG or USB function can't work if >>> it is built as module. >> >> Isn't this a limitation? > > I agree, it should work built-in or module. > >> As per the current implementation dual role works fine even with both >> USB_GADGET and HCD as module. >> >> In the real world it is unlikely that GADGET and HCD will be built-in. > > we can't make this assumption, however :-) > Agreed, we need to make sure it works with all combinations. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
