From: Alan Stern <stern@rowland.harvard.edu>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Zongmin Zhou <min_halo@163.com>,
shuah@kernel.org, valentina.manea.m@gmail.com, i@zenithal.me,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
zhouzongmin@kylinos.cn
Subject: Re: [PATCH v2] usbip: convert to use faux_device
Date: Thu, 10 Jul 2025 10:06:03 -0400 [thread overview]
Message-ID: <a735f877-e13b-498f-9eee-53ebefa8ebc9@rowland.harvard.edu> (raw)
In-Reply-To: <4478924b-fbd7-4a5a-ad0d-4fe0569b4971@linuxfoundation.org>
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.).
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.
Alan Stern
next prev parent reply other threads:[~2025-07-10 14:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 9:11 [PATCH 0/2] some changes based on faux bus Zongmin Zhou
2025-05-08 9:11 ` [PATCH 1/2] driver core:add device's platform_data set for faux device Zongmin Zhou
2025-05-08 9:45 ` Greg KH
2025-05-09 2:41 ` Zongmin Zhou
2025-05-21 10:51 ` Greg KH
2025-05-28 9:21 ` Zongmin Zhou
2025-05-08 9:11 ` [PATCH 2/2] usbip: convert to use faux_device Zongmin Zhou
2025-05-09 10:42 ` kernel test robot
2025-06-04 6:54 ` [PATCH v2] " Zongmin Zhou
2025-06-10 15:15 ` Shuah Khan
2025-06-19 11:02 ` Greg KH
2025-06-19 11:01 ` Greg KH
2025-06-20 2:16 ` Zongmin Zhou
2025-06-20 4:29 ` Greg KH
2025-06-20 9:19 ` Zongmin Zhou
2025-06-20 9:27 ` Greg KH
2025-06-20 17:26 ` Shuah Khan
2025-06-24 3:21 ` Zongmin Zhou
2025-07-01 22:56 ` Shuah Khan
2025-07-02 2:12 ` Zongmin Zhou
2025-07-02 23:54 ` Shuah Khan
2025-07-03 6:04 ` Zongmin Zhou
2025-07-08 18:16 ` Shuah Khan
2025-07-09 9:07 ` Zongmin Zhou
2025-07-09 10:06 ` Greg KH
2025-07-09 14:20 ` Alan Stern
2025-07-09 21:49 ` Shuah Khan
2025-07-09 21:57 ` Shuah Khan
2025-07-10 14:06 ` Alan Stern [this message]
2025-07-10 20:33 ` Shuah Khan
2025-07-11 5:56 ` Greg KH
2025-07-14 5:31 ` Zongmin Zhou
2025-07-09 21:33 ` Shuah Khan
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=a735f877-e13b-498f-9eee-53ebefa8ebc9@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=gregkh@linuxfoundation.org \
--cc=i@zenithal.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=min_halo@163.com \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=valentina.manea.m@gmail.com \
--cc=zhouzongmin@kylinos.cn \
/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
all inboxes | Powered by JetHome®