Re: [PATCH 0/2] v4l2-subdev/int3472: Use "privacy" as con_id for the LED lookup

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]

On Tue, 9 Sep 2025, Hans de Goede wrote:
> On 9-Sep-25 7:27 PM, Andy Shevchenko wrote:
> > On Tue, Sep 9, 2025 at 5:48 PM Hans de Goede <hansg@kernel.org> wrote:
> >>
> >> During DT-binding review for extending the V4L2 camera sensor privacy LED
> >> support to systems using devicetree, it has come up that having a "-led"
> >> suffix for the LED name / con_id is undesirable since it already is clear
> >> that it is a LED:
> >>
> >> https://lore.kernel.org/linux-media/0e030e7d-0a1a-4a00-ba18-ed26107d07fa@oss.qualcomm.com/
> >>
> >> There was discussion about making an exception for "privacy-led" since
> >> that is already used on x86/ACPI platforms, but I'm afraid that will set
> >> a bad example which ends up being copy and pasted, so lets just drop
> >> the "-led" prefix from the x86/ACPI side, which we can do since there
> >> this is only an in-kernel "API".
> > 
> > Since it's an in-kernel API, why can't these two be simply squashed?
> 
> Good question, this is only a runtime thing when running on actual
> hw with a privacy LED. So having this separately will not break
> the build in the middle.
> 
> As such it seems better to have this as 2 patches since it involves
> 2 different subsystems.

But it's still only a single logical change, and not something with 
monsterous complexity which would warrant splitting it at the subsystem 
boundary.

Or do you immediately know about something that would conflict with either 
of these changes which would warrant splitting it per subsystem to avoid 
merge challenges? If not, I agree with Andy this should just be squashed 
into a single patch.

Another question, is the "privacy_led" suffix added into pled.name still
acceptable despite the "led" suffix?

-- 
 i.