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

From: Baolin Wang
Date: Thu Oct 13 2016 - 07:47:43 EST

Hi Felipe,

On 13 October 2016 at 19:22, Felipe Balbi <balbi@xxxxxxxxxx> wrote:
> Hi,
> Janusz Dziedzic <janusz.dziedzic@xxxxxxxxx> writes:
>>>> Baolin Wang <> 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

I am sure I tested every patch I send to you. But this one is really
my mistake and I thought this is just one small change with just eye
review. I am really sorry for troubles.

> 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

Best Regards