X86 platform drivers
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Hans de Goede <hansg@kernel.org>
Cc: "Aleksandrs Vinarskis" <alex@vinarskis.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	platform-driver-x86@vger.kernel.org,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v2 1/1] media: v4l2-subdev / pdx86: int3472: Use "privacy" as con_id for the privacy LED
Date: Thu, 25 Sep 2025 19:04:13 +0300	[thread overview]
Message-ID: <aNVn_TeS--sdVFSf@kekkonen.localdomain> (raw)
In-Reply-To: <58e4a3a2-ede5-4121-99da-03a78b6d1481@kernel.org>

Hi Hans,

On Wed, Sep 24, 2025 at 12:33:38PM +0200, Hans de Goede wrote:
> Hi Sakari,
> 
> On 24-Sep-25 12:28 PM, Sakari Ailus wrote:
> > Hi Hans, Aleksandrs,
> > 
> > On Wed, Sep 24, 2025 at 11:58:38AM +0200, Hans de Goede wrote:
> >> Hi All,
> >>
> >> On 24-Sep-25 9:06 AM, Aleksandrs Vinarskis wrote:
> >>>
> >>> On Wednesday, September 10th, 2025 at 12:51, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
> >>>
> >>>>
> >>>>
> >>>> On Wed, 10 Sep 2025, Hans de Goede 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.
> >>>>>
> >>>>> Drop the "-led" suffix from the con_id in both the lookup table in
> >>>>> the int3472 code, as well as from the con_id led_get() argument in
> >>>>> the v4l2-subdev code.
> >>>>>
> >>>>> Signed-off-by: Hans de Goede hansg@kernel.org
> >>>>> ---
> >>>>> drivers/media/v4l2-core/v4l2-subdev.c | 2 +-
> >>>>> drivers/platform/x86/intel/int3472/led.c | 2 +-
> >>>>> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> 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");
> >>>>> 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;
> >>>>
> >>>>
> >>>> Acked-by: Ilpo Järvinen ilpo.jarvinen@linux.intel.com
> >>>>
> >>>
> >>> Hi all,
> >>>
> >>> Anything still pending before this patch can land? As DT-binding change that requires this [1] is already in linux-next it would be nice to land this in the same cycle.
> >>
> >> Hmm, I was under the impression this was already merged but I do not see it in:
> >>
> >> https://gitlab.freedesktop.org/linux-media/media-committers/
> >>
> >> Sakari, can you pick this one up please, preferably for
> >> 6.18 ?
> > 
> > Is the related DT binding change going to be merged for v6.18?
> 
> Just be clear / make sure we are on the same page 6.18 will be what
> is in -next now, so my request to merge this for 6.18 is a request
> to get this into -next before the merge-window which will open next
> Monday (or in the first fixes pull-req after the merge-window).

Ack, I'll pick this as a fix for v6.18.

-- 
Kind regards,

Sakari Ailus

      reply	other threads:[~2025-09-25 16:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-10 10:47 [PATCH v2 0/1] v4l2-subdev/int3472: Use "privacy" as con_id for the LED lookup Hans de Goede
2025-09-10 10:47 ` [PATCH v2 1/1] media: v4l2-subdev / pdx86: int3472: Use "privacy" as con_id for the privacy LED Hans de Goede
2025-09-10 10:51   ` Ilpo Järvinen
2025-09-24  7:06     ` Aleksandrs Vinarskis
2025-09-24  9:58       ` Hans de Goede
2025-09-24 10:28         ` Sakari Ailus
2025-09-24 10:33           ` Hans de Goede
2025-09-25 16:04             ` Sakari Ailus [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aNVn_TeS--sdVFSf@kekkonen.localdomain \
    --to=sakari.ailus@linux.intel.com \
    --cc=alex@vinarskis.com \
    --cc=andy@kernel.org \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox