Re: [PATCH 4/4] media: uvcvideo: Introduce allow_privacy_override

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

On Tue, Nov 18, 2025 at 03:09:16PM +0100, Mauro Carvalho Chehab wrote:
> On Tue, Nov 18, 2025 at 06:14:09AM -0500, Greg Kroah-Hartman wrote:
> > On Mon, Nov 17, 2025 at 08:14:19PM +0000, Ricardo Ribalda wrote:
> > > Some camera modules have XU controls that can configure the behaviour of
> > > the privacy LED.
> > > 
> > > Block mapping of those controls, unless the module is configured with
> > > a new parameter: allow_privacy_override.
> > 
> > This is not the 1990's, please do not add new module parameters, they do
> > not scale, nor work properly at all for modern hardware where you can
> > have multiple devices in the same system.
> > 
> > This isn't an agreement that we should do this feature at all, just that
> > if you do, it should NOT be a module parameter.
> 
> I agree with Greg: modprobe makes things harder specially on usb.
> 
> Also, in the specific case of privacy leds, IMO it should never be
> possible to directly disable it, not even root via a modprobe or
> runtime parameter.
> 
> Ok, as it might be some case where someone really wants to disable for his
> special pet toy. If such cases are relevant, a Kconfig parameter could
> be added (maybe depending on BROKEN), having privacy LED enabled by default. 

The feature was added by Logitech to their webcams to avoid the red
privacy LED showing as a reflection on users' glasses. Whether or not
users ended up caring, I don't know.

The situation is different for webcams embedded in devices (even if
they're internally UVC cameras), as the privacy LED is typically smaller
and less bright in those devices.

> This way, any sane distro-generated Kernel should always have the privacy
> LED on when camera is in use. 
> 
> On other words, if someone has secure boot enabled, he can be more confident
> that a distro-vendor signed Kernel will honour the privacy LED, and not
> even the root can tamper with - as BIOS access to disable secure boot would
> be needed to change it - plus, booting a non-signed kernel.

-- 
Regards,

Laurent Pinchart