On 20/06/16 12:24, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq@ti.com> writes:
>>>>> Roger Quadros <rogerq@ti.com> writes:
>>>>>> The OTG core will use struct otg_gadget_ops to
>>>>>> start/stop the gadget controller.
>>>>>>
>>>>>> The main purpose of this interface is to avoid directly
>>>>>> calling usb_gadget_start/stop() from the OTG core as they
>>>>>> wouldn't be defined in the built-in symbol table if
>>>>>> CONFIG_USB_GADGET is m.
>>>>>>
>>>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>>>> ---
>>>>>>  include/linux/usb/gadget.h | 16 ++++++++++++++++
>>>>>>  1 file changed, 16 insertions(+)
>>>>>>
>>>>>> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>>>>>> index 2dd9e6b..f4fc0aa 100644
>>>>>> --- a/include/linux/usb/gadget.h
>>>>>> +++ b/include/linux/usb/gadget.h
>>>>>> @@ -639,6 +639,22 @@ struct usb_gadget_driver {
>>>>>>  };
>>>>>>  
>>>>>>  
>>>>>> +/*-------------------------------------------------------------------------*/
>>>>>> +
>>>>>> +/**
>>>>>> + * struct otg_gadget_ops - Interface between OTG core and gadget
>>>>>> + *
>>>>>> + * Provided by the gadget core to allow the OTG core to start/stop the gadget
>>>>>> + *
>>>>>> + * @start: function to start the gadget
>>>>>> + * @stop: function to stop the gadget
>>>>>> + * @connect_control: function to connect/disconnect from the bus
>>>>>> + */
>>>>>> +struct otg_gadget_ops {
>>>>>> +	int (*start)(struct usb_gadget *gadget);
>>>>>> +	int (*stop)(struct usb_gadget *gadget);
>>>>>> +	int (*connect_control)(struct usb_gadget *gadget, bool connect);
>>>>>> +};
>>>>>
>>>>> you shouldn't need these at all. They are already part of the gadget
>>>>> framework as ->udc_start(), ->udc_stop() and ->pullup()
>>>>>
>>>>
>>>> This is to avoid the undefined symbol errors during build when OTG has is
>>>> built-in because USB (host) is built-in but GADGET is still a module.
>>>
>>> change your Kconfig dependencies. OTG layer shouldn't be built-in unless
>>> both Gadget and Host are built-in.
>>>
>>
>> That is only one side of the story.
>> What happens if OTG is (m), Host is (m) but Gadget is (built in).
>>
>> Gadget build will fail because of undefined symbol errors for all of
>> the OTG APIs.
> 
> So you created a circular dependency, right? That's not good either. I
> suggest you clean that up because this is bound to create randconfig
> build problems in the long run.
> 

We can't avoid the circular dependency.
Gadget/Host has to register with otg. otg has to use gadget & host functions.

If you have better ideas, please let us know.

cheers,
-roger