Message-ID: <ceb0f48f-8db9-40ae-769a-08e36373b922@quicinc.com>
Date:   Thu, 26 Oct 2023 17:07:49 -0700
From:   Elson Serrao <quic_eserrao@...cinc.com>
To:     Roger Quadros <rogerq@...nel.org>, <gregkh@...uxfoundation.org>,
        <Thinh.Nguyen@...opsys.com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <devicetree@...r.kernel.org>
CC:     <linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v4 3/3] usb: dwc3: Modify runtime pm ops to handle bus
 suspend




>>>>>
>>>>> While this takes care of runtime suspend case, what about system_suspend?
>>>>> Should this check be moved to dwc3_suspend_common() instead?
>>>>>
>>>>
>>>> Sure I can move these checks to dwc3_suspend_common to make it generic.
>>>
>>> Before you do that let's first decide how we want the gadget driver to behave
>>> in system_suspend case.
>>>
>>> Current behavior is to Disconnect from the Host.
>>>
>>> Earlier I was thinking on the lines that we prevent system suspend if
>>> we are not already in USB suspend. But I'm not sure if that is the right
>>> thing to do anymore. Mainly because, system suspend is a result of user
>>> request and it may not be nice to not to meet his/her request.
>>
>> Agree. Irrespective of whether USB is suspended or not it is better to honor the system suspend request from user.
>>
>>> Maybe best to leave this policy handling to user space?
>>> i.e. if user wants USB gadget operation to be alive, he will not issue
>>> system suspend?
>>>
>>
>> Sure. So below two cases
>>
>> Case1: User doesn't care if gadget operation is alive and triggers system suspend irrespective of USB suspend. Like you mentioned, current behavior already takes care of this and initiates a DISCONNECT
>>
>> Case2:  User wants gadget to stay alive and hence can trigger system suspend only when USB is suspended (there are already user space hooks that read cdev->suspended bit to tell whether USB is suspended or not for user to decide). Attempts to request system suspend when USB is not suspended, would result in a DISCONNECT.
>>
>> For supporting Case2 from gadget driver point of view, we need to extend this series by having relevant checks in suspend_common()
>>
>> Also, is it better to provide separate flags to control the gadget driver behavior for runtime suspend Vs system suspend when USB is suspended ? For example, what if we want to enable bus suspend handling for runtime suspend only and not for system suspend (Case1).
> 
> But you mentioned that for Case1, USB gadget would disconnect from Host. So USB will be in disconnected state and USB controller can be fully de-activated? Except maybe wakeup handling to bring system out of suspend on a USB plug/unplug event?
> Why do we need separate flags for?
> 

Sorry let me clarify. This is in reference to deciding how we want the 
dwc3 driver to behave in system_suspend case.

One option is to continue with the existing behavior where USB gadget 
would disconnect from Host irrespective of bus suspend state. We dont 
need any modification in this case and we can leave this series limited 
to runtime suspend only.

Second option is to stay connected IF we are in bus suspend state 
(U3/L2) otherwise DISCONNECT IF we are not in bus suspend state. The 
main motivation is to preserve the ongoing usb session
without going through a re-enumeration (ofcourse true only if we are in 
bus suspend state). This would need relevant checks in suspend_common().

Which option do you think is more suitable? IMO option2 is better. For 
example if we are in a scenario where there is a network session (over 
USB) open between Host and the device and usb bus is suspended due to 
data inactivity. Option2 would preserve the session whereas Option1 we 
would terminate this session when a system_suspend happens.

Thanks
Elson

Powered by blists - more mailing lists