Re: [PATCH v5 4/4] platform/x86: int3472: Add support for GPIO type 0x02 (strobe)

[Andy Shevchenko]

On Fri, Mar 27, 2026 at 07:10:31PM +0100, Marco Nenciarini wrote:
> Add support for 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 patch, the kernel logs "GPIO type 0x02 unknown; the sensor
> may not work" and IR sensors paired with a strobe LED cannot function.
> 
> The strobe LED is registered through the LED subsystem like the existing
> privacy LED. Unlike the privacy LED, it does not have a lookup entry
> since there is no consumer driver expecting it via led_get().
> 
> To support multiple LEDs per INT3472 device, convert the single led
> struct member to an array with a counter.

> This GPIO type was previously referred to as "ir_flood" in early
> versions of this patch series. It has been renamed to "strobe" to match
> the GPIO type name used in ACPI _DSM tables and align with common
> camera terminology for IR illuminators.

This paragraph should not be in the commit message, but...

> Signed-off-by: Marco Nenciarini <mnencia@xxxxxxxx>
> ---

...rather somewhere here (after '---' line).

> Cc: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>

...

> struct int3472_discrete_device {

>  		struct led_lookup_data lookup;
>  		char name[INT3472_LED_MAX_NAME_LEN];
>  		struct gpio_desc *gpio;
> -	} led;
> +		bool has_lookup;

Do we need it here?

> +	} leds[INT3472_MAX_LEDS];

Can't we simply check this by list_empty() in the removal stage?

*Yes, for that we always need to initialise the list pointers at adding stage.

With that being done, I would rename the parameter to add_lookup.

-- 
With Best Regards,
Andy Shevchenko