Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

[Felipe Balbi <balbi@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]


Hi,

Janusz Dziedzic <janusz.dziedzic@tieto.com> writes:
>>> Baolin Wang <baolin.wang@linaro.org> writes:
>>>>>>>>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>>>>>>>>> index 1783406..ca2ae5b 100644
>>>>>>>>>> --- a/drivers/usb/dwc3/gadget.c
>>>>>>>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>>>>>>>> @@ -241,6 +241,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned cmd,
>>>>>>>>>>       int                     susphy = false;
>>>>>>>>>>       int                     ret = -EINVAL;
>>>>>>>>>>
>>>>>>>>>> +     if (!dwc->pullups_connected)
>>>>>>>>>> +             return -ESHUTDOWN;
>>>>>>>>>> +
>>>>>>>
>>>>>>> you skip trace_dwc3_gadget_ep_cmd()
>>>>>>
>>>>>> Yes, we did not need trace here since we did not send out the command.
>>>>>>
>>>>> What in such case: enumeration will not work and this will be because
>>>>> this ESHUTDOWN or wrong pullups_connected usage. Without a trace you
>>>>> will not know where the problem is.
>>>>> In my opinion this trace could be useful.
>>>>
>>>> We have returned the '-ESHUTDOWN' error number for user to know what
>>>> happened.
>>>
>>> No, this is actually not good and Janusz has a very valid point
>>> here. When we're debugging something in dwc3, we want to rely on
>>> tracepoints to tell us what's going on. I don't want to have to add more
>>> debugging messages to print out that ESHUTDOWN error just so I can
>>> figure out what's going on. You should be patching this in a way that
>>> the tracepoint is still printed out properly.
>>
>> Fine. Will fix this in next version.
>>
>
> BTW, did you test this patch with device mode?
> Seems in my setup this fail - DWC3_DEPCMD_SETEPCONFIG for ep0out and
> gadget_start() failed (enumeration fail).
> Don't we need to queue ep0 cmds before pullup?

Baolin, it's clear to me that you're not testing any of the patches
you're sending me. I just reviewed this part of the code and we _do_
indeed enable the control pipe before connecting pullups and that *must*
be done this way, otherwise we won't be able to receive first Setup
packet from host.

How have you tested this? Against which tree?

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]