Add support for INT3472 GPIO type 0x02 which controls an IR strobe LED
used for face authentication on some laptops (e.g. Dell Pro Max 16
Premium). Without this, the kernel logs "GPIO type 0x02 unknown; the
sensor may not work" and IR sensors paired with a strobe LED cannot
function.

The series first refactors the existing LED code (patches 1-3), then
adds the new strobe LED type with multi-LED support (patch 4).

Changes in v5:
- Swapped patches 1 and 2: local variable refactor first (on pled
  names), then rename, per Andy's suggestion to reduce churn
- Dropped enum and lookup tables in favor of simple function parameters
  (string name + bool has_lookup), per Andy's review
- Multi-LED infrastructure (array, counter, has_lookup) only introduced
  in patch 4 where it is actually needed
- container_of targets struct int3472_led directly (single line)
- Used C99 for-loop variable declaration in unregister loop
- Renamed LED from ir_flood (v1-v2) to strobe (v3+) to match the GPIO
  type name in ACPI _DSM tables and align with common camera
  terminology for IR illuminators. This rename happened in v3 but was
  not documented in the changelog until now.

Marco Nenciarini (4):
  platform/x86: int3472: Use local variable for LED struct access
  platform/x86: int3472: Rename pled to led in LED registration code
  platform/x86: int3472: Parameterize LED name in registration
  platform/x86: int3472: Add support for GPIO type 0x02 (strobe)

 drivers/platform/x86/intel/int3472/discrete.c | 16 ++++-
 drivers/platform/x86/intel/int3472/led.c      | 61 +++++++++++--------
 include/linux/platform_data/x86/int3472.h     | 14 +++--
 3 files changed, 59 insertions(+), 32 deletions(-)

-- 
2.47.3

Hi Marco,

On 27-Mar-26 19:10, Marco Nenciarini wrote:
> Add support for INT3472 GPIO type 0x02 which controls an IR strobe LED
> used for face authentication on some laptops (e.g. Dell Pro Max 16
> Premium). Without this, the kernel logs "GPIO type 0x02 unknown; the
> sensor may not work" and IR sensors paired with a strobe LED cannot
> function.
> 
> The series first refactors the existing LED code (patches 1-3), then
> adds the new strobe LED type with multi-LED support (patch 4).
> 
> Changes in v5:
> - Swapped patches 1 and 2: local variable refactor first (on pled
>   names), then rename, per Andy's suggestion to reduce churn
> - Dropped enum and lookup tables in favor of simple function parameters
>   (string name + bool has_lookup), per Andy's review
> - Multi-LED infrastructure (array, counter, has_lookup) only introduced
>   in patch 4 where it is actually needed
> - container_of targets struct int3472_led directly (single line)
> - Used C99 for-loop variable declaration in unregister loop
> - Renamed LED from ir_flood (v1-v2) to strobe (v3+) to match the GPIO
>   type name in ACPI _DSM tables and align with common camera
>   terminology for IR illuminators. This rename happened in v3 but was
>   not documented in the changelog until now.

Thank you for your work on this.

Besides Andy's comment I've no comments on the code itself.

But this does expose a new userspace API in the form of
a e.g. OVTIxxxx:00::strobe_led LED class device.

We really need to get some input from the V4L2 maintainers
here on if this is a good idea, before merging this series.

Sakari the discrete (GPIO based) INT3472 power-sequencing
sensor companion device for the *IR/monochrome* sensor on various
ipu6/ipu7 lists a GPIO with type '2' which according to
previous patches from Intel translates to "strobe". Strobe
suggests it triggers a flash, but in reality it seems to
be an on/off GPIO for an IR flood LED to IR illuminate the
scene when using the IR sensor.

Since this is just a LED on/off signal exporting it as
a plain GPIO based LED class device seems to make sense.

For now this patch-series really does nothing other then
making the LED show up under /sys/class/leds . I think
eventually we will want the v4l2-core to do something
with this, like with the privacy LED. I can even imagine
a default simple mode where the v4l2-core just turns
on the LED when streaming starts and off again when
streaming stops (very much like the privacy LED) and
then in the future maybe we can extend this, e.g.
add a control on the sensor device to make this
configurable ?

Regardless of the exact way we want to deal with this
on the V4L2 side an important question for now is if
it is ok to export this as a OVTIxxxx:00::strobe_led.

I believe it should be, but we really need your input here.

My main remark on the current patch set is that IMHO
the LED name really should be: OVTIxxxx:00::ir_flood_led
since that is what it actually does, strobe is typically
related to flash LEDs which despite the naming in Intel's
side this is not.

Regards,

Hans






> 
> Marco Nenciarini (4):
>   platform/x86: int3472: Use local variable for LED struct access
>   platform/x86: int3472: Rename pled to led in LED registration code
>   platform/x86: int3472: Parameterize LED name in registration
>   platform/x86: int3472: Add support for GPIO type 0x02 (strobe)
> 
>  drivers/platform/x86/intel/int3472/discrete.c | 16 ++++-
>  drivers/platform/x86/intel/int3472/led.c      | 61 +++++++++++--------
>  include/linux/platform_data/x86/int3472.h     | 14 +++--
>  3 files changed, 59 insertions(+), 32 deletions(-)
>

Hi Hans,

Thank you for the detailed feedback.

> My main remark on the current patch set is that IMHO
> the LED name really should be: OVTIxxxx:00::ir_flood_led
> since that is what it actually does, strobe is typically
> related to flash LEDs which despite the naming in Intel's
> side this is not.

The series actually started with "ir_flood" in v1-v2. It was renamed to
"strobe" in v3 to match the GPIO type name used in Intel's ACPI _DSM
tables. But I agree with you that the userspace-visible LED name should
describe what the hardware actually does, not mirror an internal ACPI
label. I am happy to go back to "ir_flood" for the LED name.

We could keep INT3472_GPIO_TYPE_STROBE for the define (matching the ACPI
type value) but pass "ir_flood" as the con_id to the LED registration,
so userspace sees OVTIxxxx:00::ir_flood_led. Would that work for
everyone?

> We really need to get some input from the V4L2 maintainers
> here on if this is a good idea, before merging this series.

Agreed.

> I can even imagine
> a default simple mode where the v4l2-core just turns
> on the LED when streaming starts and off again when
> streaming stops (very much like the privacy LED) and
> then in the future maybe we can extend this, e.g.
> add a control on the sensor device to make this
> configurable ?

That makes a lot of sense. The current series intentionally keeps things
minimal (just exposing the LED under /sys/class/leds with no V4L2
integration), but this future direction sounds right.

I will hold off on sending v6 until we have agreement on the naming and
Sakari has had a chance to weigh in.

Regards,
Marco

Hi,

On 30-Mar-26 16:55, Marco Nenciarini wrote:
> Hi Hans,
> 
> Thank you for the detailed feedback.
> 
>> My main remark on the current patch set is that IMHO
>> the LED name really should be: OVTIxxxx:00::ir_flood_led
>> since that is what it actually does, strobe is typically
>> related to flash LEDs which despite the naming in Intel's
>> side this is not.
> 
> The series actually started with "ir_flood" in v1-v2. It was renamed to
> "strobe" in v3 to match the GPIO type name used in Intel's ACPI _DSM
> tables. But I agree with you that the userspace-visible LED name should
> describe what the hardware actually does, not mirror an internal ACPI
> label. I am happy to go back to "ir_flood" for the LED name.
> 
> We could keep INT3472_GPIO_TYPE_STROBE for the define (matching the ACPI
> type value) but pass "ir_flood" as the con_id to the LED registration,
> so userspace sees OVTIxxxx:00::ir_flood_led. Would that work for
> everyone?

That sounds good to me.

>> We really need to get some input from the V4L2 maintainers
>> here on if this is a good idea, before merging this series.
> 
> Agreed.
> 
>> I can even imagine
>> a default simple mode where the v4l2-core just turns
>> on the LED when streaming starts and off again when
>> streaming stops (very much like the privacy LED) and
>> then in the future maybe we can extend this, e.g.
>> add a control on the sensor device to make this
>> configurable ?
> 
> That makes a lot of sense. The current series intentionally keeps things
> minimal (just exposing the LED under /sys/class/leds with no V4L2
> integration), but this future direction sounds right.
> 
> I will hold off on sending v6 until we have agreement on the naming and
> Sakari has had a chance to weigh in.

Ack, lets wait for input from Sakari here.

Regards,

Hans

Hi Hans, Marco,

On Mon, Mar 30, 2026 at 05:12:21PM +0200, johannes.goede@oss.qualcomm.com wrote:
> Hi,
> 
> On 30-Mar-26 16:55, Marco Nenciarini wrote:
> > Hi Hans,
> > 
> > Thank you for the detailed feedback.
> > 
> >> My main remark on the current patch set is that IMHO
> >> the LED name really should be: OVTIxxxx:00::ir_flood_led
> >> since that is what it actually does, strobe is typically
> >> related to flash LEDs which despite the naming in Intel's
> >> side this is not.
> > 
> > The series actually started with "ir_flood" in v1-v2. It was renamed to
> > "strobe" in v3 to match the GPIO type name used in Intel's ACPI _DSM
> > tables. But I agree with you that the userspace-visible LED name should
> > describe what the hardware actually does, not mirror an internal ACPI
> > label. I am happy to go back to "ir_flood" for the LED name.
> > 
> > We could keep INT3472_GPIO_TYPE_STROBE for the define (matching the ACPI
> > type value) but pass "ir_flood" as the con_id to the LED registration,
> > so userspace sees OVTIxxxx:00::ir_flood_led. Would that work for
> > everyone?
> 
> That sounds good to me.

Seems reasonable.

> 
> >> We really need to get some input from the V4L2 maintainers
> >> here on if this is a good idea, before merging this series.
> > 
> > Agreed.
> > 
> >> I can even imagine
> >> a default simple mode where the v4l2-core just turns
> >> on the LED when streaming starts and off again when
> >> streaming stops (very much like the privacy LED) and
> >> then in the future maybe we can extend this, e.g.
> >> add a control on the sensor device to make this
> >> configurable ?
> > 
> > That makes a lot of sense. The current series intentionally keeps things
> > minimal (just exposing the LED under /sys/class/leds with no V4L2
> > integration), but this future direction sounds right.
> > 
> > I will hold off on sending v6 until we have agreement on the naming and
> > Sakari has had a chance to weigh in.
> 
> Ack, lets wait for input from Sakari here.

I wonder if there would be any deterministic ways to find the LED device
based on the sensor. It'd probably require more information via MC / V4L2
controls to allow that.

Alternatively we could use a boolean control for this, but I think I'd
avoid adding that now and rely on LED API instead.

Are there use cases for this LED, apart from Windows Hello? :-)

-- 
Regards,

Sakari Ailus

Hi Sakari,

On 30-Mar-26 22:21, Sakari Ailus wrote:
> Hi Hans, Marco,
> 
> On Mon, Mar 30, 2026 at 05:12:21PM +0200, johannes.goede@oss.qualcomm.com wrote:
>> Hi,
>>
>> On 30-Mar-26 16:55, Marco Nenciarini wrote:
>>> Hi Hans,
>>>
>>> Thank you for the detailed feedback.
>>>
>>>> My main remark on the current patch set is that IMHO
>>>> the LED name really should be: OVTIxxxx:00::ir_flood_led
>>>> since that is what it actually does, strobe is typically
>>>> related to flash LEDs which despite the naming in Intel's
>>>> side this is not.
>>>
>>> The series actually started with "ir_flood" in v1-v2. It was renamed to
>>> "strobe" in v3 to match the GPIO type name used in Intel's ACPI _DSM
>>> tables. But I agree with you that the userspace-visible LED name should
>>> describe what the hardware actually does, not mirror an internal ACPI
>>> label. I am happy to go back to "ir_flood" for the LED name.
>>>
>>> We could keep INT3472_GPIO_TYPE_STROBE for the define (matching the ACPI
>>> type value) but pass "ir_flood" as the con_id to the LED registration,
>>> so userspace sees OVTIxxxx:00::ir_flood_led. Would that work for
>>> everyone?
>>
>> That sounds good to me.
> 
> Seems reasonable.
> 
>>
>>>> We really need to get some input from the V4L2 maintainers
>>>> here on if this is a good idea, before merging this series.
>>>
>>> Agreed.
>>>
>>>> I can even imagine
>>>> a default simple mode where the v4l2-core just turns
>>>> on the LED when streaming starts and off again when
>>>> streaming stops (very much like the privacy LED) and
>>>> then in the future maybe we can extend this, e.g.
>>>> add a control on the sensor device to make this
>>>> configurable ?
>>>
>>> That makes a lot of sense. The current series intentionally keeps things
>>> minimal (just exposing the LED under /sys/class/leds with no V4L2
>>> integration), but this future direction sounds right.
>>>
>>> I will hold off on sending v6 until we have agreement on the naming and
>>> Sakari has had a chance to weigh in.
>>
>> Ack, lets wait for input from Sakari here.
> 
> I wonder if there would be any deterministic ways to find the LED device
> based on the sensor. It'd probably require more information via MC / V4L2
> controls to allow that.

Yes, the int3472 code adds a LED lookup table entry with the consumer-
device being the sensor.

So just like v4l2-subdev.c currently does:

	sd->privacy_led = led_get(sd->dev, "privacy");

it will also be able to do:

	sd->privacy_led = led_get(sd->dev, "ir_flood");

> Alternatively we could use a boolean control for this, but I think I'd
> avoid adding that now and rely on LED API instead.
> 
> Are there use cases for this LED, apart from Windows Hello? :-)

As mentioned for now we could just treat it exactly the same
as the privacy LED and simply turn it on while streaming
inside the v4l2-core / v4l2-subdev code.

This would nicely cover the face ID use-case for which
Linux implementations exist to.

And then later of some other use-case comes up we could
make this a menu-control with on/off/auto values, defaulting
to auto which would preserve the turn it on while streaming
behavior.

We do need to come up with something here, since use-cases
like Howdy (Linux face-id) will need it. My vote goes to
give it the same treatment as the privacy LED in the v4l2-core
for now making things "just work".

Alternatively we could document that userspace needs to
find the LED and turn it on itself through the LED classdev
but that will be painful for userspace to do for various
reasons including classdev access requiring root rights.

Regards,

Hans

Hi Hans,

On Tue, Mar 31, 2026 at 12:15:55PM +0200, johannes.goede@oss.qualcomm.com wrote:
> Hi Sakari,
> 
> On 30-Mar-26 22:21, Sakari Ailus wrote:
> > Hi Hans, Marco,
> > 
> > On Mon, Mar 30, 2026 at 05:12:21PM +0200, johannes.goede@oss.qualcomm.com wrote:
> >> Hi,
> >>
> >> On 30-Mar-26 16:55, Marco Nenciarini wrote:
> >>> Hi Hans,
> >>>
> >>> Thank you for the detailed feedback.
> >>>
> >>>> My main remark on the current patch set is that IMHO
> >>>> the LED name really should be: OVTIxxxx:00::ir_flood_led
> >>>> since that is what it actually does, strobe is typically
> >>>> related to flash LEDs which despite the naming in Intel's
> >>>> side this is not.
> >>>
> >>> The series actually started with "ir_flood" in v1-v2. It was renamed to
> >>> "strobe" in v3 to match the GPIO type name used in Intel's ACPI _DSM
> >>> tables. But I agree with you that the userspace-visible LED name should
> >>> describe what the hardware actually does, not mirror an internal ACPI
> >>> label. I am happy to go back to "ir_flood" for the LED name.
> >>>
> >>> We could keep INT3472_GPIO_TYPE_STROBE for the define (matching the ACPI
> >>> type value) but pass "ir_flood" as the con_id to the LED registration,
> >>> so userspace sees OVTIxxxx:00::ir_flood_led. Would that work for
> >>> everyone?
> >>
> >> That sounds good to me.
> > 
> > Seems reasonable.
> > 
> >>
> >>>> We really need to get some input from the V4L2 maintainers
> >>>> here on if this is a good idea, before merging this series.
> >>>
> >>> Agreed.
> >>>
> >>>> I can even imagine
> >>>> a default simple mode where the v4l2-core just turns
> >>>> on the LED when streaming starts and off again when
> >>>> streaming stops (very much like the privacy LED) and
> >>>> then in the future maybe we can extend this, e.g.
> >>>> add a control on the sensor device to make this
> >>>> configurable ?
> >>>
> >>> That makes a lot of sense. The current series intentionally keeps things
> >>> minimal (just exposing the LED under /sys/class/leds with no V4L2
> >>> integration), but this future direction sounds right.
> >>>
> >>> I will hold off on sending v6 until we have agreement on the naming and
> >>> Sakari has had a chance to weigh in.
> >>
> >> Ack, lets wait for input from Sakari here.
> > 
> > I wonder if there would be any deterministic ways to find the LED device
> > based on the sensor. It'd probably require more information via MC / V4L2
> > controls to allow that.
> 
> Yes, the int3472 code adds a LED lookup table entry with the consumer-
> device being the sensor.
> 
> So just like v4l2-subdev.c currently does:
> 
> 	sd->privacy_led = led_get(sd->dev, "privacy");
> 
> it will also be able to do:
> 
> 	sd->privacy_led = led_get(sd->dev, "ir_flood");
> 
> > Alternatively we could use a boolean control for this, but I think I'd
> > avoid adding that now and rely on LED API instead.
> > 
> > Are there use cases for this LED, apart from Windows Hello? :-)
> 
> As mentioned for now we could just treat it exactly the same
> as the privacy LED and simply turn it on while streaming
> inside the v4l2-core / v4l2-subdev code.
> 
> This would nicely cover the face ID use-case for which
> Linux implementations exist to.
> 
> And then later of some other use-case comes up we could
> make this a menu-control with on/off/auto values, defaulting
> to auto which would preserve the turn it on while streaming
> behavior.
> 
> We do need to come up with something here, since use-cases
> like Howdy (Linux face-id) will need it. My vote goes to
> give it the same treatment as the privacy LED in the v4l2-core
> for now making things "just work".
> 
> Alternatively we could document that userspace needs to
> find the LED and turn it on itself through the LED classdev
> but that will be painful for userspace to do for various
> reasons including classdev access requiring root rights.

That was actually my concern as well.

Still, if we bind this to the privacy LED now and the LED will effectively
be powered whenever the camera is streaming, we can't drop that interaction
in the future as doing so would break existing users. I'm not sure if there
would ever be a need though.

Either way, I'm starting to feel the V4L2 control might actually be the
best way to go from here.

-- 
Kind regards,

Sakari Ailus

Hi,

On 31-Mar-26 23:28, Sakari Ailus wrote:
> Hi Hans,
> 
> On Tue, Mar 31, 2026 at 12:15:55PM +0200, johannes.goede@oss.qualcomm.com wrote:
>> Hi Sakari,
>>
>> On 30-Mar-26 22:21, Sakari Ailus wrote:
>>> Hi Hans, Marco,
>>>
>>> On Mon, Mar 30, 2026 at 05:12:21PM +0200, johannes.goede@oss.qualcomm.com wrote:
>>>> Hi,
>>>>
>>>> On 30-Mar-26 16:55, Marco Nenciarini wrote:
>>>>> Hi Hans,
>>>>>
>>>>> Thank you for the detailed feedback.
>>>>>
>>>>>> My main remark on the current patch set is that IMHO
>>>>>> the LED name really should be: OVTIxxxx:00::ir_flood_led
>>>>>> since that is what it actually does, strobe is typically
>>>>>> related to flash LEDs which despite the naming in Intel's
>>>>>> side this is not.
>>>>>
>>>>> The series actually started with "ir_flood" in v1-v2. It was renamed to
>>>>> "strobe" in v3 to match the GPIO type name used in Intel's ACPI _DSM
>>>>> tables. But I agree with you that the userspace-visible LED name should
>>>>> describe what the hardware actually does, not mirror an internal ACPI
>>>>> label. I am happy to go back to "ir_flood" for the LED name.
>>>>>
>>>>> We could keep INT3472_GPIO_TYPE_STROBE for the define (matching the ACPI
>>>>> type value) but pass "ir_flood" as the con_id to the LED registration,
>>>>> so userspace sees OVTIxxxx:00::ir_flood_led. Would that work for
>>>>> everyone?
>>>>
>>>> That sounds good to me.
>>>
>>> Seems reasonable.
>>>
>>>>
>>>>>> We really need to get some input from the V4L2 maintainers
>>>>>> here on if this is a good idea, before merging this series.
>>>>>
>>>>> Agreed.
>>>>>
>>>>>> I can even imagine
>>>>>> a default simple mode where the v4l2-core just turns
>>>>>> on the LED when streaming starts and off again when
>>>>>> streaming stops (very much like the privacy LED) and
>>>>>> then in the future maybe we can extend this, e.g.
>>>>>> add a control on the sensor device to make this
>>>>>> configurable ?
>>>>>
>>>>> That makes a lot of sense. The current series intentionally keeps things
>>>>> minimal (just exposing the LED under /sys/class/leds with no V4L2
>>>>> integration), but this future direction sounds right.
>>>>>
>>>>> I will hold off on sending v6 until we have agreement on the naming and
>>>>> Sakari has had a chance to weigh in.
>>>>
>>>> Ack, lets wait for input from Sakari here.
>>>
>>> I wonder if there would be any deterministic ways to find the LED device
>>> based on the sensor. It'd probably require more information via MC / V4L2
>>> controls to allow that.
>>
>> Yes, the int3472 code adds a LED lookup table entry with the consumer-
>> device being the sensor.
>>
>> So just like v4l2-subdev.c currently does:
>>
>> 	sd->privacy_led = led_get(sd->dev, "privacy");
>>
>> it will also be able to do:
>>
>> 	sd->privacy_led = led_get(sd->dev, "ir_flood");
>>
>>> Alternatively we could use a boolean control for this, but I think I'd
>>> avoid adding that now and rely on LED API instead.
>>>
>>> Are there use cases for this LED, apart from Windows Hello? :-)
>>
>> As mentioned for now we could just treat it exactly the same
>> as the privacy LED and simply turn it on while streaming
>> inside the v4l2-core / v4l2-subdev code.
>>
>> This would nicely cover the face ID use-case for which
>> Linux implementations exist to.
>>
>> And then later of some other use-case comes up we could
>> make this a menu-control with on/off/auto values, defaulting
>> to auto which would preserve the turn it on while streaming
>> behavior.
>>
>> We do need to come up with something here, since use-cases
>> like Howdy (Linux face-id) will need it. My vote goes to
>> give it the same treatment as the privacy LED in the v4l2-core
>> for now making things "just work".
>>
>> Alternatively we could document that userspace needs to
>> find the LED and turn it on itself through the LED classdev
>> but that will be painful for userspace to do for various
>> reasons including classdev access requiring root rights.
> 
> That was actually my concern as well.
> 
> Still, if we bind this to the privacy LED now

To be clear my suggestion is to treat it the same as we
currently treat privacy-LEDs (auto-on while streaming) but
have a separate code-path, or at least a separate LED name
("ir_flood" vs "privacy") to allow different behavior in
the future.

> and the LED will effectively
> be powered whenever the camera is streaming,

Ack.

> we can't drop that interaction
> in the future as doing so would break existing users.

Ack.

> I'm not sure if there would ever be a need though.

Ack.

> Either way, I'm starting to feel the V4L2 control might actually be the
> best way to go from here.

I think we can postpone adding a ctrl to if a use-case needing
different behavior ever shows up (which is unlikely?) .

This ctrl can then be a menu ctrl with auto/on/off values
defaulting to auto and auto preserving the on-while-streaking
behavior, so not breaking existing users.

TL;DR: my proposal is:

1. Name the new LED classdev ir_flood[_led] including
   adding an "ir_flood" LED lookup with the sensor as
   consuming device of the LED.

2. Make v4l2-core turn the ir_flood on automatically while
   streaming, just like it does for a "privacy" LED currently
   (mostly re-using the existing privacy LED code).

3. If in the future userspace needs more fine-grained control
   at a ir_flood V4L2 menu control on the sensor with
   auto/on/off values, defaulting to auto which preserves
   the behavior from 2.

Regards,

Hans

On 01-Apr-26 15:38, johannes.goede@oss.qualcomm.com wrote:
> TL;DR: my proposal is:
> 
> 1. Name the new LED classdev ir_flood[_led] including
>    adding an "ir_flood" LED lookup with the sensor as
>    consuming device of the LED.
> 
> 2. Make v4l2-core turn the ir_flood on automatically while
>    streaming, just like it does for a "privacy" LED currently
>    (mostly re-using the existing privacy LED code).
> 
> 3. If in the future userspace needs more fine-grained control
>    at a ir_flood V4L2 menu control on the sensor with
>    auto/on/off values, defaulting to auto which preserves
>    the behavior from 2.

This plan sounds good to me.

I have a v8 ready that addresses your feedback on patch 4/4: the LED
lookup is now always registered (for ir_flood too), removing the type
parameter and the conditional switch-case. Shall I go ahead and send it?

Marco

Hi,

On 1-Apr-26 19:13, Marco Nenciarini wrote:
> On 01-Apr-26 15:38, johannes.goede@oss.qualcomm.com wrote:
>> TL;DR: my proposal is:
>>
>> 1. Name the new LED classdev ir_flood[_led] including
>>    adding an "ir_flood" LED lookup with the sensor as
>>    consuming device of the LED.
>>
>> 2. Make v4l2-core turn the ir_flood on automatically while
>>    streaming, just like it does for a "privacy" LED currently
>>    (mostly re-using the existing privacy LED code).
>>
>> 3. If in the future userspace needs more fine-grained control
>>    at a ir_flood V4L2 menu control on the sensor with
>>    auto/on/off values, defaulting to auto which preserves
>>    the behavior from 2.
> 
> This plan sounds good to me.
> 
> I have a v8 ready that addresses your feedback on patch 4/4: the LED
> lookup is now always registered (for ir_flood too), removing the type
> parameter and the conditional switch-case. Shall I go ahead and send it?

Since Andy indicated he is ok with that approach, yes please
submit v8 and then this should be ready for merging.

Regards,

Hans

Hi Sakari,

Thank you for looking at this.

On Mon, Mar 30, 2026 at 11:21:32PM +0300, Sakari Ailus wrote:
> I wonder if there would be any deterministic ways to find the LED device
> based on the sensor. It'd probably require more information via MC / V4L2
> controls to allow that.

The LED name includes the sensor's ACPI device name (e.g.
OVTI9734:00::ir_flood_led), so userspace can match by naming
convention. For proper integration, the privacy LED already has a
led_get() lookup keyed on the sensor's ACPI name, and future work
could add a similar lookup for the IR flood LED once there is a
consumer driver.

> Alternatively we could use a boolean control for this, but I think I'd
> avoid adding that now and rely on LED API instead.

Agreed, LED API keeps things simple for now and leaves room for V4L2
integration later.

> Are there use cases for this LED, apart from Windows Hello? :-)

Face authentication is the primary one. On Linux, projects like Howdy
can use it. More broadly, any application that needs the IR sensor
benefits since without this patch the kernel refuses to register the
GPIO and the sensor cannot function at all.

Since everyone agrees on "ir_flood_led" for the name and the LED API
approach, I will prepare v6 with that rename plus Andy's cosmetic
fixes.

Regards,
Marco

On Fri, Mar 27, 2026 at 07:10:27PM +0100, Marco Nenciarini wrote:
> Add support for INT3472 GPIO type 0x02 which controls an IR strobe LED
> used for face authentication on some laptops (e.g. Dell Pro Max 16
> Premium). Without this, the kernel logs "GPIO type 0x02 unknown; the
> sensor may not work" and IR sensors paired with a strobe LED cannot
> function.
> 
> The series first refactors the existing LED code (patches 1-3), then
> adds the new strobe LED type with multi-LED support (patch 4).

Thanks for the update! I have given mostly cosmetic change requests, but
the main one is to rename local variable in the first patch pled --> led.

-- 
With Best Regards,
Andy Shevchenko