Re: [PATCH v3 3/3] media: uvcvideo: skip streaming restart after hibernation snapshot

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Jul 23, 2026 at 09:39:55AM +0800, Haowen Tu wrote:
> On Wed, Jul 22, 2026 at 11:06:20PM +0300, Laurent Pinchart wrote:
> > On Thu, Jun 18, 2026 at 09:31:33AM +0800, Haowen Tu wrote:
> > > After the hibernation snapshot is created, devices are resumed with
> > > PMSG_THAW before the image is written and the system is powered off.
> > > Restarting an active UVC stream during this phase reinitializes the
> > > camera and visibly turns its indicator LED back on.
> > > 
> > > Skip only the UVC streaming hardware restart while the snapshot is
> > > available.  The driver's frozen state and clock are still updated before
> > > the check, and a subsequent UVC suspend can stop the stream and select
> > > alternate setting 0 as usual.
> >
> > Why is that desired (both the decision to only block the resume of the
> > video interface, and the decision to not block the next suspend) ?
> 
> The intention is not to block the whole video interface resume callback.
> The callback still clears stream->frozen and resets the stream clock
> before the new check.  The patch only skips the final streaming hardware
> restart, namely uvc_commit_video() and uvc_video_start_transfer().

Yes, I understand what the patch does.

> In the earlier version the check was placed before those state updates.
> After Oliver pointed out the image write failure path, I moved it later
> in uvc_video_resume().  If swsusp_write() fails, the system continues
> running in the original kernel, and the driver should not be left with
> stream->frozen still set from the preceding FREEZE suspend.

Does that mean that, if swsusp_write() fails, the camera will be left in
a hybrid state where the control interface has been resumed but the
streaming interface will not have been restarted ?

> That is the part that reconfigures the camera and restarts USB video
> transfers, which is what turns the camera indicator LED back on during
> the hibernation image-write phase.  The control interface resume path is
> left unchanged because it is not the source of that visible side effect,
> and because I do not want to change more of the UVC PM flow than needed
> for this case.
> 
> The later suspend is also intentionally left unchanged.  The patch should
> not alter the PM core sequencing.  If the platform hibernation path or an
> error recovery path later asks the UVC streaming interface to suspend
> again, uvc_video_suspend() can still run the existing cleanup path and
> select alternate setting 0 as usual.  This keeps the interface in the
> same state that the existing suspend path expects, instead of introducing
> a special case where the later suspend is skipped too.
> 
> > > uvcvideo does not provide a shutdown
> > > callback that requires the streaming hardware to be restarted first.
> > > 
> > > This is a device-specific use of pm_hibernation_snapshot_done().  The
> > > helper does not cause other drivers or USB core to skip THAW resume.
> >
> > I don't think this sentence belongs to the commit message.
> 
> Agreed, I can drop that sentence from the commit message in the next
> version.  It belongs more in the cover letter, if anywhere.

-- 
Regards,

Laurent Pinchart