[RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?

[RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?

[Haowen Tu]

Hi,

I'm looking for feedback on a USB/PM design question that came up while
investigating a UVC hibernation issue.

In the hibernation flow, after the memory snapshot has been created, the
kernel briefly resumes devices in order to write the image to storage.
On the successful hibernation path, the system is then powered off. For
a USB camera that was actively streaming before hibernation, this means
the USB resume path runs during that intermediate THAW phase, even
though the final RESTORE path has not happened yet.

From the driver's point of view, that THAW phase is not semantically the
same as the later RESTORE path after booting from the image.

The difficulty is that USB interface drivers currently get

    int (*suspend)(struct usb_interface *intf, pm_message_t message);

but resume-side callbacks are only

    int (*resume)(struct usb_interface *intf);
    int (*reset_resume)(struct usb_interface *intf);

so by the time a USB interface driver's resume path runs, it has no
direct way to distinguish a hibernation image-write THAW from the later
RESTORE path.

The immediate trigger here is UVC, where resuming the streaming path
during that THAW phase can turn the camera LED back on and cause other
visible device activity even though the system is about to power off.
More generally, review feedback on that patch was that solving this in
individual leaf drivers would not scale well if other USB interface
drivers ever need similar behavior.

So the question is whether USB interface drivers should be able to
distinguish these two phases, and if so, what the right interface would
be.

Possible directions could include:

  1. Exposing the phase distinction to USB interface drivers
  2. Handling it inside usbcore
  3. Adding a USB-specific callback or other mechanism for this
     transition

I'm intentionally not proposing a concrete API in this RFC yet. I'd
first like to understand whether this should be considered a real USB PM
interface issue, and if so, which direction would be the least
intrusive and most maintainable.

Thanks,
Haowen Tu

Re: [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?

[Oliver Neukum]

On 29.04.26 05:36, Haowen Tu wrote:
  
First, to which extent is the issue specific to USB? I suppose
you'd see the same issue on a camera connected via PCI.

> In the hibernation flow, after the memory snapshot has been created, the
> kernel briefly resumes devices in order to write the image to storage.

Yes. But you cannot just restrict the thaw to storage devices.
You also want

a) displays (to show the user what is going on)
b) keyboards (sysrq key)
c) anything used for logging
d) devices for the visually impaired

> On the successful hibernation path, the system is then powered off. For

Keyword: successful

> a USB camera that was actively streaming before hibernation, this means
> the USB resume path runs during that intermediate THAW phase, even
> though the final RESTORE path has not happened yet.

Yes, though it will not happen if the writeout fails.

>  From the driver's point of view, that THAW phase is not semantically the
> same as the later RESTORE path after booting from the image.

That is the key point. In the error case it is.
  
> The difficulty is that USB interface drivers currently get
> 
>      int (*suspend)(struct usb_interface *intf, pm_message_t message);
> 
> but resume-side callbacks are only
> 
>      int (*resume)(struct usb_interface *intf);
>      int (*reset_resume)(struct usb_interface *intf);

That depends on whether the device has lost state.
  
> so by the time a USB interface driver's resume path runs, it has no
> direct way to distinguish a hibernation image-write THAW from the later
> RESTORE path.

That is not true. A thaw should call resume(). A restore after STD
should call reset_resume().
  
> The immediate trigger here is UVC, where resuming the streaming path
> during that THAW phase can turn the camera LED back on and cause other
> visible device activity even though the system is about to power off.
> More generally, review feedback on that patch was that solving this in
> individual leaf drivers would not scale well if other USB interface
> drivers ever need similar behavior.

Storage and UAS devices need to thaw. As well as the devices listed above.

> So the question is whether USB interface drivers should be able to
> distinguish these two phases, and if so, what the right interface would
> be.
> 
> Possible directions could include:
> 
>    1. Exposing the phase distinction to USB interface drivers
>    2. Handling it inside usbcore

Not possible. Some devices need to be thawed. Writing an image
to a USB device must work. At the very minimum you need a flag
and a mechanism to handle a failed writeout.

>    3. Adding a USB-specific callback or other mechanism for this
>       transition
> 
> I'm intentionally not proposing a concrete API in this RFC yet. I'd
> first like to understand whether this should be considered a real USB PM
> interface issue, and if so, which direction would be the least
> intrusive and most maintainable.

I am sorry, but your basic assumption that all USB devices can be handled
in the same way is not correct.

	Regards
		Oliver

Re: [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?

[Alan Stern]

On Wed, Apr 29, 2026 at 11:36:17AM +0800, Haowen Tu wrote:
> Hi,
> 
> I'm looking for feedback on a USB/PM design question that came up while
> investigating a UVC hibernation issue.
> 
> In the hibernation flow, after the memory snapshot has been created, the
> kernel briefly resumes devices in order to write the image to storage.
> On the successful hibernation path, the system is then powered off. For
> a USB camera that was actively streaming before hibernation, this means
> the USB resume path runs during that intermediate THAW phase, even
> though the final RESTORE path has not happened yet.
> 
> From the driver's point of view, that THAW phase is not semantically the
> same as the later RESTORE path after booting from the image.
> 
> The difficulty is that USB interface drivers currently get
> 
>     int (*suspend)(struct usb_interface *intf, pm_message_t message);
> 
> but resume-side callbacks are only
> 
>     int (*resume)(struct usb_interface *intf);
>     int (*reset_resume)(struct usb_interface *intf);
> 
> so by the time a USB interface driver's resume path runs, it has no
> direct way to distinguish a hibernation image-write THAW from the later
> RESTORE path.
> 
> The immediate trigger here is UVC, where resuming the streaming path
> during that THAW phase can turn the camera LED back on and cause other
> visible device activity even though the system is about to power off.

You don't know that.  As Oliver pointed out, if writing out the system's 
hibernation image fails, the system will not power off.

And anyway, what's wrong with turning the camera LED back on and 
performing other visible device activity during the THAW phase of 
hibernation?  If it helps, don't think of this as momentarily resuming 
activity during a shutdown -- instead think of the preceding FREEZE 
phase as momentarily pausing all activity while the system is still 
running.

Note that during the FREEZE phase, devices are not required to go to 
low power, just to stop transferring data.  It would be okay to leave 
the LED on during the FREEZE.

> More generally, review feedback on that patch was that solving this in
> individual leaf drivers would not scale well if other USB interface
> drivers ever need similar behavior.

It's not clear to me that anything needs to be solved.

> So the question is whether USB interface drivers should be able to
> distinguish these two phases, and if so, what the right interface would
> be.
> 
> Possible directions could include:
> 
>   1. Exposing the phase distinction to USB interface drivers
>   2. Handling it inside usbcore
>   3. Adding a USB-specific callback or other mechanism for this
>      transition
> 
> I'm intentionally not proposing a concrete API in this RFC yet. I'd
> first like to understand whether this should be considered a real USB PM
> interface issue, and if so, which direction would be the least
> intrusive and most maintainable.

Before anything gets changed, you should provide a good justification 
for changing it.

Alan Stern

Re: [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?

[Haowen Tu]

Hi Oliver, Alan,

Thanks for the feedback.

I think my original RFC title and framing were too narrow.

What originally triggered this discussion was a UVC camera: during the
THAW phase used for hibernation image writeout, the camera's streaming
resume path runs again and can turn the indicator LED back on. From that
observation, I started by looking at the USB side.

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.

So the real issue I wanted to ask about is closer to this:

  during hibernation image writeout, should PM resume all previously
  frozen devices, or is there any room for a more minimal resume of only
  the devices required for writeout and their dependencies?

If writeout succeeds, the system will power off afterward, which made me
wonder whether every previously frozen device must be resumed at that
stage in the same way it would be for ordinary recovery. If not,
avoiding unnecessary resume work in that phase might also reduce the
time spent before final poweroff, although I do not have measurements
for that. On the other hand, if writeout fails, the system needs to
continue running, so the remaining devices would still have to be
recovered correctly. I agree that this failure path makes the problem
much more subtle than I described in the RFC.

I also agree with Oliver's point that this cannot be expressed as
"storage devices only". In practice, any such approach would need to
account for dependencies and for other classes of devices that may still
matter during the writeout phase.

So at this point I am no longer trying to argue for a USB-specific
interface change. Instead, I am trying to understand whether this is a
valid PM/hibernate design question at all, namely whether the writeout
phase should conceptually be treated as:

  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.

I do not have a concrete implementation in mind yet, and I am not sure
whether such an approach would even fit well with the current PM core
model. I first wanted to check whether this is considered a valid
problem to discuss.

If the answer is that the current full-THAW behavior is simply the
intended model, that is also useful for me. In that case, I should not
treat the UVC behavior as evidence of a missing USB-side mechanism.

Thanks,
Haowen

Re: [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?

[Oliver Neukum]

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

Re: [RFC] USB/PM: should USB interface drivers distinguish hibernation THAW from RESTORE?

[Alan Stern]

On Thu, Apr 30, 2026 at 10:14:33AM +0800, Haowen Tu wrote:
> So the real issue I wanted to ask about is closer to this:
> 
>   during hibernation image writeout, should PM resume all previously
>   frozen devices, or is there any room for a more minimal resume of only
>   the devices required for writeout and their dependencies?
> 
> If writeout succeeds, the system will power off afterward, which made me
> wonder whether every previously frozen device must be resumed at that
> stage in the same way it would be for ordinary recovery. If not,
> avoiding unnecessary resume work in that phase might also reduce the
> time spent before final poweroff, although I do not have measurements
> for that. On the other hand, if writeout fails, the system needs to
> continue running, so the remaining devices would still have to be
> recovered correctly. I agree that this failure path makes the problem
> much more subtle than I described in the RFC.
> 
> I also agree with Oliver's point that this cannot be expressed as
> "storage devices only". In practice, any such approach would need to
> account for dependencies and for other classes of devices that may still
> matter during the writeout phase.
> 
> So at this point I am no longer trying to argue for a USB-specific
> interface change. Instead, I am trying to understand whether this is a
> valid PM/hibernate design question at all, namely whether the writeout
> phase should conceptually be treated as:
> 
>   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.
> 
> I do not have a concrete implementation in mind yet, and I am not sure
> whether such an approach would even fit well with the current PM core
> model. I first wanted to check whether this is considered a valid
> problem to discuss.
> 
> If the answer is that the current full-THAW behavior is simply the
> intended model, that is also useful for me. In that case, I should not
> treat the UVC behavior as evidence of a missing USB-side mechanism.

As I understand it, the system works the way it currently does because 
there was no good way to tell which devices needed to be powered up for 
storing the memory image.  It's not just the storage device itself, but 
all the other things it depends on, some of which might not be its 
ancestors in the device tree.

By far, the simplest and most reliable solution was to just power 
everything up.

Alan Stern