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

[Haowen Tu <tuhaowen@uniontech.com>]

Hi Hans,

On Wed, Jul 29, 2026 at 09:29:03AM +0200, Hans de Goede wrote:
> Right, so the purpose here is to avoid the LED turning back on and
> to speedup the hibernate?
>
> IOW except for the LED turning back on and things taking slightly
> longer everything works correctly with the current code, right ?

Yes, the current code is functionally correct in the sense that the
hibernation flow can complete and the camera can be restored afterwards.

The issue was reported as a user-visible privacy concern.  When an active
UVC camera enters hibernation, the camera LED turns off during the freeze
phase but turns back on after the snapshot has been created, while the
system is writing the hibernation image.  From the user's point of view,
this looks like the camera has been activated again during the
hibernation transition.

I am not claiming that this causes image data to be exposed.  The problem
is the unnecessary hardware reactivation and the resulting unexpected
privacy-indicator behavior during a system power transition.

Avoiding the restart also avoids unnecessary device work in this window,
but I do not intend to make performance the main argument here.  The
primary goal is to avoid the unexpected camera reactivation.

> I'm wondering if it would not be better to solve this in userspace
> and have userspace stop the streaming before hibernation ?

That would help when all userspace camera users cooperate, but I don't
think it is equivalent to handling this in the driver.

UVC is a generic driver and the kernel PM transition can happen while an
application is actively streaming.  Relying on every userspace camera
consumer to stop streaming before hibernation would make the behavior
depend on userspace policy and application support.  The driver already
knows whether streaming was active at freeze time, and it is also the
component that restarts the hardware during resume, so it can avoid this
specific unnecessary hardware restart more reliably.

> Hmm, the way you word this sound like this is a problem at the USB
> layer. But I think this is more of a short-coming in the generic
> device model.
>
> To clarify AFAIK the actual USB device to which the interfaces belong
> also does not get a specific PM message here, right ?
>
> The reason I'm asking is because the way this is worded in the commit
> message makes it sounds like this might be something which could
> be solved in the USB subsystem which I do not think is the case ?

Yes, that is my understanding as well.  The USB device resume path does
not expose the specific PM transition type to the UVC interface driver's
resume callback.

The problem was observed in UVC, and the immediate reason there is that
the UVC resume path is reached through usb_driver.resume(), which does
not receive the PM event.  But I agree that this should not be worded as
a USB subsystem bug.

My earlier thought was to expose the THAW/RESTORE distinction through
USB, but that would still need coordination with the PM core, and it
would only cover USB drivers.  If other non-USB drivers have similar
device-specific reasons to avoid work during the post-snapshot THAW
phase, they would need their own handling too.

So I can reword the commit message to avoid implying that this is a USB
core issue.  Something like:

  Some resume callback paths, including the UVC path through
  usb_driver.resume(), do not receive the PM event and therefore cannot
  distinguish the transient post-snapshot THAW phase from the later
  RESTORE phase using their local callback arguments.

The helper is intended to expose only the hibernation snapshot state.
Whether it is safe or useful to defer any work remains a driver-specific
decision.

Thanks,
Haowen