[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <x2xheosw24fecqjjv4fmj2t3i53k2ypyvmkkkvmv6xtdwsherd@e5klkm3ou4g7>
Date: Tue, 18 Nov 2025 15:09:16 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Ricardo Ribalda <ribalda@...omium.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Hans de Goede <hansg@...nel.org>, Mauro Carvalho Chehab <mchehab@...nel.org>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 4/4] media: uvcvideo: Introduce allow_privacy_override
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.
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,
Mauro
Powered by blists - more mailing lists