Re: [PATCH v3 4/4] media: uvcvideo: RFC: Convert allow_privacy_override into Kconfig

[Ricardo Ribalda <ribalda@chromium.org>]

Hi Greg

On Wed, 18 Mar 2026 at 15:17, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Mar 16, 2026 at 01:34:47PM +0000, Ricardo Ribalda wrote:
> > This patch is just shared for discussion purposes! Do not land.
> >
> > In a perfect world, after a deprecation process, we will be able to
> > remove allow_privacy_override and block all privacy related controls.
>
> Why add something you are only going to remove in the future?  What has
> changed to require this now, and will change in the future to make it
> not needed?

Currently, any application with camera access can manipulate the
privacy LED. I believe this is a security flaw; ideally, the kernel
should block all such controls by default.

However, blocking these controls immediately might be seen as a
regression for certain users. I added allow_privacy_override to:
- Prevent breaking existing workflows immediately upon a kernel update.
- Give users time to report why they still need manual LED control.

The goal is to gather these use cases over the next 1–2 years. Once we
understand the legitimate needs, we can either implement a proper
specialized mechanism for them or move the toggle to a Kconfig option
for those who explicitly need to opt-in to the old behavior or simply
remove the toggle altogether.

For the record, identified use cases so far:
- Old hardware with red LEDs that reflect on glasses. (Likely a dying niche).
- Using cameras as baby monitors where the LED disturbs sleep.
(Arguably solvable with a piece of tape on the LED, but still a
reported use case).

>
> > If there is any usecase out in the field that resists, we shall move it
> > into a Kconfig.
>
> What does this mean?  How will anyone know to "resist"?

My phrasing was poor, sorry about that. What I mean is: if, after a
deprecation period, we find there are still legitimate reasons to
allow LED overrides, we will move the functionality behind a Kconfig
option (e.g., USB_VIDEO_CLASS_ALLOW_PRIVACY_OVERRIDE) or other option.
If no one reports a need for it, we simply remove the override
capability entirely.

>
> > This patch shows how the transition to Kconfig can look.
>
> I'm confused as to what you want to do here...

This patch is just a RFC to demonstrate the final state if we decide a
Kconfig option is necessary. The actual plan is to land patches 1-3
first, wait for feedback, and only then decide if we need the Kconfig
transition or a full removal or something else.

>
> greg k-h



--
Ricardo Ribalda