LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: Felipe Balbi <balbi@kernel.org>
Cc: <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Date: Mon, 5 Mar 2018 11:45:58 +0200 [thread overview]
Message-ID: <a907787a-dea2-5f15-3d25-693680a42b71@ti.com> (raw)
In-Reply-To: <87po4i3o1v.fsf@linux.intel.com>
Felipe,
On 05/03/18 10:49, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <rogerq@ti.com> writes:
>>> Roger Quadros <rogerq@ti.com> writes:
>>>> In the following test we get stuck by sleeping forever in _dwc3_set_mode()
>>>> after which dual-role switching doesn't work.
>>>>
>>>> On dra7-evm's dual-role port,
>>>> - Load g_zero gadget driver and enumerate to host
>>>> - suspend to mem
>>>> - disconnect USB cable to host and connect otg cable with Pen drive in it.
>>>> - resume system
>>>> - we sleep indefinitely in _dwc3_set_mode due to.
>>>> dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->
>>>> dwc3_gadget_stop()->wait_event_lock_irq()
>>>>
>>>> Let's clear the DWC3_EP_END_TRANSFER_PENDING flag on all endpoints
>>>> so we don't wait in dwc3_gadget_stop().
>>>>
>>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>>> ---
>>>> drivers/usb/dwc3/gadget.c | 14 ++++++++++++++
>>>> 1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>>> index 2bda4eb..0a360da 100644
>>>> --- a/drivers/usb/dwc3/gadget.c
>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>> @@ -3273,6 +3273,20 @@ int dwc3_gadget_init(struct dwc3 *dwc)
>>>>
>>>> void dwc3_gadget_exit(struct dwc3 *dwc)
>>>> {
>>>> + int epnum;
>>>> + unsigned long flags;
>>>> +
>>>> + spin_lock_irqsave(&dwc->lock, flags);
>>>> + for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
>>>> + struct dwc3_ep *dep = dwc->eps[epnum];
>>>> +
>>>> + if (!dep)
>>>> + continue;
>>>> +
>>>> + dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
>>>> + }
>>>> + spin_unlock_irqrestore(&dwc->lock, flags);
>>>> +
>>>> usb_del_gadget_udc(&dwc->gadget);
>>>> dwc3_gadget_free_endpoints(dwc);
>>>
>>> free endpoints is a better place for this. It's already going to free
>>> the memory anyway. Might as well clear all flags to 0 there.
>>>
>>
>> But it won't solve the deadlock issue. Since dwc3_gadget_free_endpoints()
>> is called after usb_del_gadget_udc() and the deadlock happens when
>>
>> usb_del_gadget_udc()->udc_stop()->dwc3_gadget_stop()->wait_event_lock_irq()
>>
>> and DWC3_EP_END_TRANSFER_PENDING flag is set.
>
> indeed. Iterating twice over the entire endpoint list seems
> wasteful. Perhaps we just shouldn't wait when removing the UDC since
> that's essentially what this patch will do, right? If you clear the flag
> before calling ->udc_stop(), this means the loop in dwc3_gadget_stop()
> will do nothing. Might as well remove it.
>
This means that we will never wait for DWC3_EP_END_TRANSFER_PENDING to clear
in dwc3_gadget_stop() like we used to. This is perfectly fine, right?
It makes sense to me as dwc3_gadget_stop() calls __dwc3_gadget_stop() which
masks all interrupts and nobody will ever clear that flag if it was set.
And there is no point in clearing the DWC3_EP_END_TRANSFER_PENDING flag
in dwc3_gadget_free_endpoints() since we're freeing the dwc3_ep memory there.
dwc3_gadget_init_endpoints() will start with a clean slate.
--
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2018-03-05 9:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 11:22 [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume Roger Quadros
2018-02-28 3:04 ` Baolin Wang
2018-02-28 9:55 ` Roger Quadros
2018-02-28 7:53 ` Felipe Balbi
2018-02-28 9:59 ` Roger Quadros
2018-03-05 8:49 ` Felipe Balbi
2018-03-05 9:45 ` Roger Quadros [this message]
2018-03-05 10:41 ` Baolin Wang
2018-03-05 11:03 ` Roger Quadros
2018-03-05 11:06 ` Felipe Balbi
2018-03-05 11:14 ` Roger Quadros
2018-03-05 11:25 ` Baolin Wang
2018-03-05 11:27 ` Felipe Balbi
2018-03-09 9:19 ` Roger Quadros
2018-03-09 9:23 ` Felipe Balbi
2018-03-09 9:26 ` Roger Quadros
2018-03-09 9:49 ` Roger Quadros
2018-03-09 10:39 ` Felipe Balbi
2018-03-09 10:36 ` Felipe Balbi
2018-03-05 11:25 ` Felipe Balbi
2018-03-09 12:47 ` [PATCH v2] " Roger Quadros
2018-03-16 10:34 ` Roger Quadros
2018-03-16 11:00 ` Felipe Balbi
2018-03-16 11:03 ` Roger Quadros
2018-03-16 11:43 ` Minas Harutyunyan
2018-03-16 12:25 ` Felipe Balbi
2018-03-17 6:33 ` Minas Harutyunyan
2018-03-19 8:54 ` Felipe Balbi
2018-03-19 11:36 ` Minas Harutyunyan
2018-03-19 13:53 ` Minas Harutyunyan
2018-04-10 6:29 ` Minas Harutyunyan
2018-04-10 7:31 ` Felipe Balbi
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=a907787a-dea2-5f15-3d25-693680a42b71@ti.com \
--to=rogerq@ti.com \
--cc=balbi@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).