linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wesley Cheng <wcheng@codeaurora.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: balbi@kernel.org, gregkh@linuxfoundation.org,
	Thinh.Nguyen@synopsys.com, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, jackp@codeaurora.org
Subject: Re: [PATCH 1/2] usb: dwc3: gadget: Allow runtime suspend if UDC unbinded
Date: Tue, 3 Nov 2020 13:53:01 -0800	[thread overview]
Message-ID: <57d56507-e2f7-bce8-2445-95820db25fc8@codeaurora.org> (raw)
In-Reply-To: <20201103200716.GA1538425@rowland.harvard.edu>



On 11/3/2020 12:07 PM, Alan Stern wrote:
> On Tue, Nov 03, 2020 at 11:02:25AM -0800, Wesley Cheng wrote:
>>
>>
>> On 10/28/2020 6:07 PM, Alan Stern wrote:
>>>> --- a/drivers/usb/dwc3/gadget.c
>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>> @@ -1995,6 +1995,11 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
>>>>  	unsigned long		flags;
>>>>  	int			ret;
>>>>  
>>>> +	if (pm_runtime_suspended(dwc->dev)) {
>>>> +		pm_request_resume(dwc->dev);
>>>> +		return 0;
>>>> +	}
>>>
>>> Isn't this racy?  What happens if the controller was active but a 
>>> runtime suspend occurs right here?
>>>
>>> Alan Stern
>>>
>>
>> Hi Alan,
>>
>> Ah, yes you're right.  I was hoping that the PM runtime layer would be
>> utilizing the spinlock when reading out the runtime status, but even
>> then, we wouldn't be able to catch intermediate states with this API
>> (i.e. RPM_RESUMING or RPM_SUSPENDING)
>>
>> Tried a few different approaches, and came up with something like the
>> following:
>>
>> static int dwc3_gadget_pullup(struct usb_gadget *g, int is_on)
>> {
>> ...
>> 	ret = pm_runtime_get_sync(dwc->dev);
>> 	if (!ret) {
>> 		pm_runtime_put(dwc->dev);
>> 		return 0;
>> 	}
>> 	...
>> 	pm_runtime_put(dwc->dev);
>>
>> 	return 0;
>> }
>>
>> I think this should be good to address your concern.  The only way we
>> would be able to ensure that the runtime PM state doesn't enter
>> idle/suspend is if we increment the usage count for the duration we're
>> accessing the DWC3 registers.  With the synchronous PM runtime resume
>> call, we can also ensure that no pending runtime suspends are executing
>> in parallel while running this code.
> 
> That's correct.
> 
>> The check for the zero return value would be for avoiding running the
>> DWC3 run stop sequence for the case where we executed the runtime PM
>> resume, as the DWC3 runtime PM resume routine will set the run stop bit
>> in there.
> 
> If you need to add an explanation of this subtle point in your email 
> message, then you should add a similar explanation as a comment in the 
> code.  And don't forget to check for ret < 0 (i.e., a resume error).
> 

Hi Alan,

Got it, will do.  Yes, I'll include the error conditions as well in the
actual change.  Thanks again!

Thanks

Regards,
Wesley Cheng

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2020-11-03 21:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 23:43 [PATCH 0/2] Allow DWC3 runtime suspend if UDC is unbinded Wesley Cheng
2020-10-28 23:43 ` [PATCH 1/2] usb: dwc3: gadget: Allow runtime suspend if UDC unbinded Wesley Cheng
2020-10-29  1:07   ` Alan Stern
2020-11-03 19:02     ` Wesley Cheng
2020-11-03 20:07       ` Alan Stern
2020-11-03 21:53         ` Wesley Cheng [this message]
2020-10-28 23:43 ` [PATCH 2/2] usb: dwc3: gadget: Preserve UDC max speed setting Wesley Cheng
2020-10-29  0:43   ` Thinh Nguyen
2020-10-29  2:00     ` Wesley Cheng
2020-10-29  2:57       ` Thinh Nguyen
2020-10-29  6:29         ` Thinh Nguyen

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=57d56507-e2f7-bce8-2445-95820db25fc8@codeaurora.org \
    --to=wcheng@codeaurora.org \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jackp@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).