[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <05201136-5c67-47e7-a3f1-a7af051a2a00@quicinc.com>
Date: Wed, 27 Sep 2023 12:58:49 +0530
From: Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To: Alan Stern <stern@...land.harvard.edu>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Francesco Dolcini <francesco.dolcini@...adex.com>,
Badhri Jagan Sridharan <badhri@...gle.com>,
Michael Grzeschik <m.grzeschik@...gutronix.de>,
Ivan Orlov <ivan.orlov0322@...il.com>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<quic_ppratap@...cinc.com>, <quic_wcheng@...cinc.com>,
<quic_jackp@...cinc.com>
Subject: Re: [PATCH v4] usb: gadget: udc: Handle gadget_connect failure during
bind operation
On 9/27/2023 2:54 AM, Alan Stern wrote:
> On Wed, Sep 27, 2023 at 01:54:34AM +0530, Krishna Kurapati PSSNV wrote:
>>
>>
>> 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.
>
> Isn't that what you want? I thought the whole purpose of this patch was
> to make it so that configfs would realize when
> usb_udc_connect_control_locked() had failed. So you should be happy
> that the log shows a failure occurred.
> >> 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.
>
> "Diff in the logs in v4"? What does that mean? A diff is a comparison
> between two text files (often between before-and-after versions of a
> source code file). Why would you expect a diff to show up in the logs?
>
> This revised patch looks okay to me.
>
Thanks for the confirmation. Will push v5.
Regards,
Krishna,
Powered by blists - more mailing lists