Messages in this thread | | | From | Baolin Wang <> | Date | Thu, 13 Oct 2016 19:30:17 +0800 | Subject | Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically |
| |
Hi,
On 13 October 2016 at 19:22, Felipe Balbi <balbi@kernel.org> wrote: > > 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.
I am very sorry for this mistake. Since the original patch is adding some 'pullups_connected' check in other places to avoid queuing requests, but you suggested me this only affected the endpoint command transfer, so I just follow your advice without one clear testing. I really sorry for that. Please ignore this patch and I promise I will test it enough before sending out any patches. Sorry again for troubles.
> > How have you tested this? Against which tree? > > -- > balbi
-- Baolin.wang Best Regards
| |