linux-kernel - Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a subdevice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241125125629.GB32280@pendragon.ideasonboard.com>
Date: Mon, 25 Nov 2024 14:56:29 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Ricardo Ribalda <ribalda@...omium.org>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	Yunke Cao <yunkec@...omium.org>, Hans Verkuil <hverkuil@...all.nl>
Subject: Re: [PATCH v2 0/6] media: uvcvideo: Implement the Privacy GPIO as a
 subdevice

On Mon, Nov 25, 2024 at 01:31:49PM +0100, Hans de Goede wrote:
> Hi Ricardo,
> 
> On 10-Nov-24 5:04 PM, Ricardo Ribalda wrote:
> > On Sun, 10 Nov 2024 at 16:14, Laurent Pinchart wrote:
> 
> <snip>
> 
> >>> Can we start powering up the device during try/set fmt and then
> >>> implement the format caching as an improvement?
> >>
> >> This sounds worth trying. We'll need to test it on a wide range of
> >> devices though, both internal and external.
> 
> Ack, as mentioned in the other mail which I just send I think
> this is worth trying.
> 
> > We still need a plan for asynchronous controls.
> 
> As I mentioned in that other email I think we can do the same there.
> 
> So basically delay powering up the camera from /dev/video# open till
> the first moment we actually need to communicate to the camera and
> track per file-handle if we did a usb_autopm_get_interface() for
> that file-handle and if yes, then do the put-interface on file-handle
> close.
> 
> > And we have to decide if we stop supporting the uvc button (maybe we
> > can start by moving USB_VIDEO_CLASS_INPUT_EVDEV to staging and see
> > what happens?)
> 
> As I mentioned in other threads I do not think that the button
> only working changing from:
> 
> "only works when /dev/video# is open"
> 
> to:
> 
> "only works when streaming from /dev/video#"
> 
> (or actually only works when some action on the camera which
> requires it to be powered-on has been done).
> 
> is a big deal, since most apps which open /dev/video# for
> a longer time will almost always do so to actually do something
> with the camera, at which point the button will work just as
> before.
> 
> And for apps which only do a short-lived open of /dev/video#
> the button does not work with the current code either.
> 
> TL;DR: IMHO it is fine if the button only works when streaming.

I'm fine with that, we can reconsider if people complain. It would be
painful though, as it could mean reverting everything we'll build
related to power management from now on until someone notices the new
behaviour, which could easily take a year. The risk is low, but the
consequences serious.

-- 
Regards,

Laurent Pinchart