LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Roger Quadros <rogerq@ti.com>
To: Felipe Balbi <balbi@kernel.org>, Baolin Wang <baolin.wang@linaro.org>
Cc: USB <linux-usb@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Date: Fri, 9 Mar 2018 11:19:37 +0200	[thread overview]
Message-ID: <5bc56ef5-66b1-d40c-1639-e748fe18cdbd@ti.com> (raw)
In-Reply-To: <87h8puwyn5.fsf@linux.intel.com>

On 05/03/18 13:27, Felipe Balbi wrote:
> 
> Hi,
> 
> Baolin Wang <baolin.wang@linaro.org> writes:
>>>>>>>>>>  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.
>>>>>
>>>>> I don't think so. It can not mask the endpoint events, please check
>>>>> the events which will be masked in DEVTEN register. The reason why we
>>>>> should wait for DWC3_EP_END_TRANSFER_PENDING to clear is that,
>>>>> sometimes the DWC3_DEPEVT_EPCMDCMPLT event will be triggered later
>>>>> than 100us, but now we may have freed the gadget irq which will cause
>>>>> crash.
>>>>
>>>> We could mask command complete events as soon as ->udc_stop() is called,
>>>> right? Hmm, actually, __dwc3_gadget_stop() already clears DEVTEN
>>>> completely.
>>>
>>> But which bit in DEVTEN says Endpoint events are disabled?
>>
>> When we set up the DWC3_DEPCMD_ENDTRANSFER command in
>> dwc3_stop_active_transfer(), we can do not set DWC3_DEPCMD_CMDIOC,
>> then there will no endpoint command complete interrupts I think.
>>
>> cmd |= DWC3_DEPCMD_CMDIOC;
> 
> I remember some part of the databook mandating CMDIOC to be set. We
> could test it out without and see if anything blows up. I would,
> however, require a lengthy comment explaining that we're deviating from
> databook revision x.yya, section foobar because $reasons. :-)
> 

This is what the v3.10 databook says

"When issuing an End Transfer command, software must set the CmdIOC bit (field 8) so that an Endpoint
Command Complete event is generated after the transfer ends. This is necessary to synchronize the
conclusion of system bus traffic before the End Transfer command is completed."

with a note
"If GUCTL2[Rst_actbitlater] is set, Software can poll the completion of the End Transfer
command by polling the command active bit to be cleared to 0."

fyi.
Rst_actbitlater - "Enable clearing of the command active bit for the ENDXFER
command after the command execution is completed.
This bit is valid in device mode only."

So I'd prefer not to clear CMDIOC for all cases.

Could we some how just tackle the dwc3_gadget_exit case like I did in this patch?

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

  reply	other threads:[~2018-03-09  9:19 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
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 [this message]
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=5bc56ef5-66b1-d40c-1639-e748fe18cdbd@ti.com \
    --to=rogerq@ti.com \
    --cc=balbi@kernel.org \
    --cc=baolin.wang@linaro.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).