Re: [PATCH v4 4/4] media: uvcvideo: defer streaming restart after hibernation snapshot

[Haowen Tu]

Hi Laurent, Alan,

On Thu, Jul 30, 2026 at 06:38:17PM +0300, Laurent Pinchart wrote:
> Something like that. I'm very biased as I mostly work on multimedia
> devices, but it feels to me that for many drivers the current
> hibernation procedure is too complex. Those drivers don't need to
> differentiate suspend and hibernation, they only need to be instructed
> to suspend at some point, and resume later. Resuming could occur when
> the system is woken up, or when hibernation fails in the THAW phase, and
> those drivers wouldn't care to differentiate between the two. Seeing an
> extra resume + suspend cycle due to the hibernation machinery needing to
> write the image to disk, and having to handle that cycle manually as in
> this series, is additional complexity that (unless I'm missing
> something) could be handled by the PM core.

I agree.  This was actually close to what I considered before trying the
smaller UVC-specific approach.

My initial thought was that the PM core could distinguish the
post-snapshot resume used for writing the hibernation image from the
later path where the original kernel continues running.  In that model,
devices that do not need to be resumed during the image-write phase
could be marked accordingly.  They would remain suspended after FREEZE,
and would only be resumed if the original kernel continues running
instead of powering down.

That would avoid making each driver open-code the same kind of
post-snapshot THAW check and recovery handling.  It would also avoid the
notifier ordering issue in v4, because the PM core would keep the normal
device ordering when resuming the skipped devices.

The reason I did not start with that approach is that it looked like a
larger PM core change.  It needs a clear definition of which devices need
to be resumed for hibernation image writeout, and it needs to preserve
parent-device and storage-stack dependencies.  It also needs to handle
the case Alan mentioned, where the restore kernel cannot restore the
image and sends THAW before continuing; that path should not be skipped
in the same way as the post-snapshot image-writeout resume.

So v4 was an attempt to keep the change local to the observed UVC issue
while still handling the swsusp_write() failure path.  But I agree that,
if this is viewed as a more general PM problem, a PM-core solution with
an explicit skip and recovery mechanism would be cleaner than a UVC
notifier.

Rafael, would such a PM-core direction be acceptable to explore?  For
example, a device flag indicating that the device does not need to be
resumed during the post-snapshot image-write phase, with PM resuming
those skipped devices if the original kernel continues running, before
userspace is thawed?

If that direction is preferred, I can rework the series around a
PM-core-managed mechanism.

Thanks,
Haowen