Re: [PATCH v2] usbip: convert to use faux_device

[Shuah Khan <skhan@linuxfoundation.org>]

On 7/9/25 15:49, Shuah Khan wrote:
> On 7/9/25 08:20, Alan Stern wrote:
>> On Wed, Jul 09, 2025 at 12:06:57PM +0200, Greg KH wrote:
>>> On Wed, Jul 09, 2025 at 05:07:24PM +0800, Zongmin Zhou wrote:
>>>>>> In fact, I've experimented with adding PM hooks to the faux bus,
>>>>>> and found that faux bus devices then behave identically to platform
>>>>>> bus devices during suspend/resume.
>>>>>> See the attachment.
>>>>>>
>>>>>
>>>>> Thanks for checking this scenario. No surprises here.
>>>> Another part of my purpose in doing this is that the vhci-hcd driver seems
>>>> should still retain suspend/resume hooks. Therefore, the faux bus should
>>>> add corresponding hooks to allow the driver to call its own pm functions.
>>>> Though currently don't know how to fix this problem yet.
>>>
>>> I have no problem with adding the pm functions to the faux bus, BUT it
>>> needs to make sense as to why they would be needed at all as this is not
>>> a "real" device or bus that should need to do anything when
>>> suspend/resume happens.
>>
>> The unique problem faced by vhci-hcd is that the devices it controls
>> reside on external computer systems that have a lot of their own state,
>> much more than ordinay USB devices have.  Consequently vhci-hcd may need
>> to do more work for a PM transition than a normal driver would.
>>
>> As an analogy, suppose you're running a program that has an open TCP
>> connection to an external server.  If you suspend your computer, it
>> won't be able to send the TCP keepalive packets that the server expects,
>> and the server will eventually close the connection.  Then when your
>> computer resumes, your program may misbehave when it finds its
>> connection has spontaneously been closed for no apparent reason.
>>
> 
> Right. We have a few too many moving pieces here:
> 
> usbipd (user-space)
> vhci_hcd and the usb devices it creates
> 
> usbip_host, stub driver that proxies between the device
> on the server and vhci_client.
> 
> PM can be complex and it has to do lot more than it currently
> does on both server and client end to support seamlessly.
> 
> The current suspend took the approach of refusing suspend
> which doesn't work since usb devices underneath hang in
> usb_dev_resume(). Looks like this usb device is treated like
> a real device bu usb core. Is there a way to have usb core
> PM (suspend and resume) handle them as virtual? Would it
> help to use "supports_autosuspend" to disable suspend and
> resume?

Would it work if usb_disable_autosuspend() on the devices
that hang off its vitual bus?

thanks,
-- Shuah