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

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Jul 10, 2025 at 02:33:42PM -0600, Shuah Khan wrote:
> On 7/10/25 08:06, Alan Stern wrote:
> > On Wed, Jul 09, 2025 at 03:57:35PM -0600, Shuah Khan wrote:
> > > On 7/9/25 15:49, Shuah Khan wrote:
> > > > 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?
> > 
> > You have to consider PM on both the host and client.  And you have to
> > consider both runtime PM and system PM (that is, suspend to RAM,
> > hibernate, etc.).
> 
> This would be as a fix for the existing suspend hang issue.
> 
> > 
> > On the server, any sort of suspend will interrupt the connection.
> > usb_disable_autosuspend() will prevent runtime suspends, but you
> > shouldn't try to prevent system suspends.  Instead, the usbip driver on
> > the server should have its suspend routine close the connection to the
> > client (rather as if the server's user had unplugged the device).
> > 
> > On the client, you've got a choice for how to handle runtime PM.  You
> > can leave it enabled, and when the client decides to suspend the device,
> > tell the server's driver.  The server driver can then attempt to do a
> > runtime suspend on the physical device.  (You might need to add a new
> > type of message to the USBIP protocol to accomplish this; I don't know
> > the details.)  Alternatively, you can forbid runtime suspend on the
> > client entirely, although it would be nice if you could avoid this.
> > 
> > System PM on the client can be handled more less the same as runtime PM.
> 
> Correct. This has to be a complete solution that syncs up server and client
> side. I am going to look into implementing this - it might be possible to
> do this in user-space. Either way this will require changes to the protocol
> very likely.
> 
> Greg, Zongmin Zhou, let's hold off on this conversion yo faux bus for now.
> I will spend time looking at if we can find PM solution that works end to end
> for server and client.

Ok, thanks!