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

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

[Hans de Goede]

Hi All,

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".

Note both patches do need to be merged at the same time to avoid breakage.
Since the changes are tiny I think it would be best to just have Sakari
merge them both through the linux-media tree.

Ilpo can you give your ack for patch 2/2 getting merged through
the linux-media tree?

Regards,

Hans


Hans de Goede (2):
  media: v4l2-subdev: Use "privacy" as con_id when getting the privacy
    LED
  platform/x86: int3472: Use "privacy" as con_id for the LED lookup

 drivers/media/v4l2-core/v4l2-subdev.c    | 2 +-
 drivers/platform/x86/intel/int3472/led.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.51.0

[PATCH 1/2] media: v4l2-subdev: Use "privacy" as con_id when getting the privacy LED

[Hans de Goede]

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.

Drop the "-led" suffix from the con_id argument to led_get().

Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Note this needs to be merged in the same kernel cycle as the matching
"platform/x86: int3472: Use "privacy" as con_id for the LED lookup"
patch.
---
 drivers/media/v4l2-core/v4l2-subdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c
index 113eb74eb7c1..babcc1120354 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -2602,7 +2602,7 @@ EXPORT_SYMBOL_GPL(v4l2_subdev_is_streaming);
 int v4l2_subdev_get_privacy_led(struct v4l2_subdev *sd)
 {
 #if IS_REACHABLE(CONFIG_LEDS_CLASS)
-	sd->privacy_led = led_get(sd->dev, "privacy-led");
+	sd->privacy_led = led_get(sd->dev, "privacy");
 	if (IS_ERR(sd->privacy_led) && PTR_ERR(sd->privacy_led) != -ENOENT)
 		return dev_err_probe(sd->dev, PTR_ERR(sd->privacy_led),
 				     "getting privacy LED\n");
-- 
2.51.0

[PATCH 2/2] platform/x86: int3472: Use "privacy" as con_id for the LED lookup

[Hans de Goede]

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.

Drop the "-led" suffix from the privacy LED's lookup table con_id.

Signed-off-by: Hans de Goede <hansg@kernel.org>
---
Note this needs to be merged in the same kernel cycle as the matching
"media: v4l2-subdev: Use "privacy" as con_id when getting the privacy LED"
patch.
---
 drivers/platform/x86/intel/int3472/led.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel/int3472/led.c b/drivers/platform/x86/intel/int3472/led.c
index f1d6d7b0cb75..b1d84b968112 100644
--- a/drivers/platform/x86/intel/int3472/led.c
+++ b/drivers/platform/x86/intel/int3472/led.c
@@ -43,7 +43,7 @@ int skl_int3472_register_pled(struct int3472_discrete_device *int3472, struct gp
 
 	int3472->pled.lookup.provider = int3472->pled.name;
 	int3472->pled.lookup.dev_id = int3472->sensor_name;
-	int3472->pled.lookup.con_id = "privacy-led";
+	int3472->pled.lookup.con_id = "privacy";
 	led_add_lookup(&int3472->pled.lookup);
 
 	return 0;
-- 
2.51.0

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

[Andy Shevchenko]

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?


-- 
With Best Regards,
Andy Shevchenko

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

[Hans de Goede]

Hi Andy,

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.

Regards,

Hans

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

[Sakari Ailus]

Hi Hans, Andy, Ilpo,

On Tue, Sep 09, 2025 at 10:40:35PM +0200, Hans de Goede wrote:
> Hi Andy,
> 
> 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.

Seems good to me.

Ilpo: are you fine with merging this via the media tree?

-- 
Kind regards,

Sakari Ailus

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

[Ilpo Järvinen]

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

On Wed, 10 Sep 2025, Sakari Ailus wrote:

> Hi Hans, Andy, Ilpo,
> 
> On Tue, Sep 09, 2025 at 10:40:35PM +0200, Hans de Goede wrote:
> > Hi Andy,
> > 
> > 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.
> 
> Seems good to me.
> 
> Ilpo: are you fine with merging this via the media tree?

Yes, but please take the v2 instead which has the changes squashed 
together.

-- 
 i.

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

[Ilpo Järvinen]

[-- 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.

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

[Hans de Goede]

Hi Ilpo,

On 10-Sep-25 11:09 AM, Ilpo Järvinen wrote:
> 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.

Ok, since both you and Andy are in favor of squashing the 2 patches
together I'll send out a v2 with the 2 patches squashed into
1 patch.

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

That is just the name of the directory added under /sys/class/leds for
the LED some others, e.g. "phy0-led" also use a led suffix, so IMHO it
is fine to keep this as is.

Regards,

Hans

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

[Ilpo Järvinen]

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

On Wed, 10 Sep 2025, Hans de Goede wrote:

> Hi Ilpo,
> 
> On 10-Sep-25 11:09 AM, Ilpo Järvinen wrote:
> > 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.
> 
> Ok, since both you and Andy are in favor of squashing the 2 patches
> together I'll send out a v2 with the 2 patches squashed into
> 1 patch.
>
> > Another question, is the "privacy_led" suffix added into pled.name still
> > acceptable despite the "led" suffix?
> 
> That is just the name of the directory added under /sys/class/leds for
> the LED some others, e.g. "phy0-led" also use a led suffix, so IMHO it
> is fine to keep this as is.

Okay, I'd no strong opinion on it but it felt like a similar case so 
asked. We can leave it as is.

-- 
 i.