From: Oliver Neukum <oneukum@suse.com>
To: Haowen Tu <tuhaowen@uniontech.com>, stern@rowland.harvard.edu
Cc: oneukum@suse.com, gregkh@linuxfoundation.org, rafael@kernel.org,
linux-usb@vger.kernel.org, linux-pm@vger.kernel.org,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
laurent.pinchart@ideasonboard.com, hansg@kernel.org,
mchehab@kernel.org, pavel@kernel.org, lenb@kernel.org,
kernel@uniontech.com
Subject: Re: [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?
Date: Thu, 30 Apr 2026 09:44:07 +0200 [thread overview]
Message-ID: <8591a0ab-2d53-4223-99e6-fdc15851f737@suse.com> (raw)
In-Reply-To: <20260430021433.2083281-1-tuhaowen@uniontech.com>
On 30.04.26 04:14, Haowen Tu wrote:
Hi,
> But after your replies, I agree that this is not really a USB-specific
> problem. The more fundamental question seems to be whether, in the
> current S4 flow, resuming the full device set at that point is the
> intended model, or whether there is any room for resuming only the
> subset of devices needed for image writeout and whatever else must
> remain functional during that phase.
In principle you could do so. Your problem would be
a) computing the subset of devices that need not be thawed
b) error handling
> 1. a full THAW of the suspended system, as it is today, or
> 2. potentially a narrower resume of only the devices needed for
> writeout, followed by broader recovery only if writeout fails.
Well, that is a question of motivation. Why do you want to avoid
thawing devices? What advantage justifies deviating from the simple
model?
If you really wanted to do this, the implementation would be rather
straight forward. The difficult question is deciding whether you
want to do it at all. Do you have systems in which going STD is
critical in terms of performance?
Regards
Oliver
next prev parent reply other threads:[~2026-04-30 7:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 3:36 [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE? Haowen Tu
2026-04-29 8:42 ` Oliver Neukum
2026-04-29 14:21 ` Alan Stern
2026-04-30 2:14 ` Haowen Tu
2026-04-30 7:44 ` Oliver Neukum [this message]
2026-05-04 1:04 ` Alan Stern
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=8591a0ab-2d53-4223-99e6-fdc15851f737@suse.com \
--to=oneukum@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=hansg@kernel.org \
--cc=kernel@uniontech.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tuhaowen@uniontech.com \
/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