Re: [PATCH v10 06/14] usb: gadget.h: Add OTG to gadget interface

From: Roger Quadros
Date: Mon Jun 20 2016 - 05:50:51 EST


On 20/06/16 12:24, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq@xxxxxx> writes:
>>>>> Roger Quadros <rogerq@xxxxxx> 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@xxxxxx>
>>>>>> ---
>>>>>> 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

Attachment: signature.asc
Description: OpenPGP digital signature