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

[Oliver Neukum <oneukum@suse.com>]

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