Linux USB
 help / color / mirror / Atom feed
From: Krishna Kurapati PSSNV <quic_kriskura@quicinc.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Francesco Dolcini <francesco.dolcini@toradex.com>,
	Badhri Jagan Sridharan <badhri@google.com>,
	Michael Grzeschik <m.grzeschik@pengutronix.de>,
	Ivan Orlov <ivan.orlov0322@gmail.com>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<quic_ppratap@quicinc.com>, <quic_wcheng@quicinc.com>,
	<quic_jackp@quicinc.com>
Subject: Re: [PATCH v4] usb: gadget: udc: Handle gadget_connect failure during bind operation
Date: Wed, 27 Sep 2023 01:54:34 +0530	[thread overview]
Message-ID: <f2bd7593-eff9-46ac-a94b-964eb4787740@quicinc.com> (raw)
In-Reply-To: <62083b55-0b78-4ebc-ab78-1c1d99f92507@quicinc.com>



On 9/27/2023 1:36 AM, Krishna Kurapati PSSNV wrote:
>>>   drivers/usb/gadget/udc/core.c | 23 +++++++++++++++++++----
>>>   1 file changed, 19 insertions(+), 4 deletions(-)
>>>
>>>   static void vbus_event_work(struct work_struct *work)
>>> @@ -1604,12 +1608,23 @@ static int gadget_bind_driver(struct device 
>>> *dev)
>>>       }
>>>       usb_gadget_enable_async_callbacks(udc);
>>>       udc->allow_connect = true;
>>> -    usb_udc_connect_control_locked(udc);
>>> +    ret = usb_udc_connect_control_locked(udc);
>>> +    if (ret) {
>>> +        mutex_unlock(&udc->connect_lock);
>>> +        goto err_connect_control;
>>> +    }
>>> +
>>>       mutex_unlock(&udc->connect_lock);
>>>       kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
>>>       return 0;
>>> + err_connect_control:
>>> +    usb_gadget_disable_async_callbacks(udc);
>>> +    if (gadget->irq)
>>> +        synchronize_irq(gadget->irq);
>>> +    usb_gadget_udc_stop_locked(udc);
>>
>> Not good -- usb_gadget_udc_stop_locked() expects you to be holding
>> udc->connect_lock, but you just dropped the lock!  Also, you never set
>> udc->allow_connect back to false.
>>
>> You should move the mutex_unlock() call from inside the "if" statement
>> to down here, and add a line for udc->allow_connect.
>>
> 
> Hi Alan,
> 
>   Thanks for the review. Will push v5 addressing the changes.
> 
> 
Hi Alan,

I tried out the following diff:

-       usb_udc_connect_control_locked(udc);
+       ret = usb_udc_connect_control_locked(udc);
+       if (ret)
+               goto err_connect_control;
+
         mutex_unlock(&udc->connect_lock);

         kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE);
         return 0;

+ err_connect_control:
+       udc->allow_connect = false;
+       usb_gadget_disable_async_callbacks(udc);
+       if (gadget->irq)
+               synchronize_irq(gadget->irq);
+       usb_gadget_udc_stop_locked(udc);
+       mutex_unlock(&udc->connect_lock);
+

If I clear UDC and fail dwc3 soft reset on purpose, I see UDC_store failing:

#echo a600000.usb > /sys/kernel/config/usb_gadget/g1/UDC
[  127.394087] dwc3 a600000.usb: request 000000003f43f907 was not queued 
to ep0out
[  127.401637] udc a600000.usb: failed to start g1: -110
[  127.406841] configfs-gadget.g1: probe of gadget.0 failed with error -110
[  127.413809] UDC core: g1: couldn't find an available UDC or it's busy

The same output came when I tested v4 as well. Every time soft_reset 
would fail when I try to write to UDC, UDC_store fails and above log 
will come up. Can you help confirm if the diff above is proper as I 
don't see any diff in the logs in v4 and about to push v5.

Regards,
Krishna,

  reply	other threads:[~2023-09-26 20:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-26 19:37 [PATCH v4] usb: gadget: udc: Handle gadget_connect failure during bind operation Krishna Kurapati
2023-09-26 19:54 ` Alan Stern
2023-09-26 20:06   ` Krishna Kurapati PSSNV
2023-09-26 20:24     ` Krishna Kurapati PSSNV [this message]
2023-09-26 21:24       ` Alan Stern
2023-09-27  7:28         ` Krishna Kurapati PSSNV

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2bd7593-eff9-46ac-a94b-964eb4787740@quicinc.com \
    --to=quic_kriskura@quicinc.com \
    --cc=badhri@google.com \
    --cc=francesco.dolcini@toradex.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ivan.orlov0322@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.grzeschik@pengutronix.de \
    --cc=quic_jackp@quicinc.com \
    --cc=quic_ppratap@quicinc.com \
    --cc=quic_wcheng@quicinc.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox