On 10/05/16 11:12, Felipe Balbi wrote:

Hi,

Roger Quadros [off-list ref] writes:

quoted

On 10/05/16 06:14, Peter Chen wrote:

quoted

On Mon, May 09, 2016 at 12:45:38PM +0300, Roger Quadros wrote:

quoted

On 06/05/16 12:41, Peter Chen wrote:

quoted

On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote:

quoted

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 <redacted>
Acked-by: Peter Chen <redacted>

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.

quoted

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