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 :-) -- balbi
Attachment:
signature.asc
Description: PGP signature
