[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871szkv6hq.fsf@linux.intel.com>
Date: Thu, 13 Oct 2016 14:22:09 +0300
From: Felipe Balbi <balbi@...nel.org>
To: Janusz Dziedzic <janusz.dziedzic@...to.com>,
Baolin Wang <baolin.wang@...aro.org>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Mark Brown <broonie@...nel.org>,
USB <linux-usb@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically
Hi,
Janusz Dziedzic <janusz.dziedzic@...to.com> writes:
>>> Baolin Wang <baolin.wang@...aro.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
Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)
Powered by blists - more mailing lists