Messages in this thread | | | From | Felipe Balbi <> | Subject | Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface | Date | Tue, 10 May 2016 11:12:32 +0300 |
| |
Hi,
Roger Quadros <rogerq@ti.com> 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@ti.com> >>>>> Acked-by: Peter Chen <peter.chen@nxp.com> >>>> >>>> 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 [unhandled content-type:application/pgp-signature]
| |