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.
Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
---
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
drivers/platform/x86/intel/int3472/discrete.c | 16 +++++++-
drivers/platform/x86/intel/int3472/led.c | 38 +++++++++++--------
include/linux/platform_data/x86/int3472.h | 11 ++++--
3 files changed, 44 insertions(+), 21 deletions(-)
diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index 57c3b2c..4c03845 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -215,6 +215,10 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
*con_id = "privacy-led";
*gpio_flags = GPIO_ACTIVE_HIGH;
break;
+ case INT3472_GPIO_TYPE_STROBE:
+ *con_id = "strobe";
+ *gpio_flags = GPIO_ACTIVE_HIGH;
+ break;
case INT3472_GPIO_TYPE_HOTPLUG_DETECT:
*con_id = "hpd";
*gpio_flags = GPIO_ACTIVE_HIGH;
@@ -248,6 +252,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
*
* 0x00 Reset
* 0x01 Power down
+ * 0x02 Strobe
* 0x0b Power enable
* 0x0c Clock enable
* 0x0d Privacy LED
@@ -331,6 +336,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
break;
case INT3472_GPIO_TYPE_CLK_ENABLE:
case INT3472_GPIO_TYPE_PRIVACY_LED:
+ case INT3472_GPIO_TYPE_STROBE:
case INT3472_GPIO_TYPE_POWER_ENABLE:
case INT3472_GPIO_TYPE_HANDSHAKE:
gpio = skl_int3472_gpiod_get_from_temp_lookup(int3472, agpio, con_id, gpio_flags);
@@ -348,7 +354,13 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
break;
case INT3472_GPIO_TYPE_PRIVACY_LED:
- ret = skl_int3472_register_led(int3472, gpio, "privacy");
+ ret = skl_int3472_register_led(int3472, gpio, "privacy", true);
+ if (ret)
+ err_msg = "Failed to register LED\n";
+
+ break;
+ case INT3472_GPIO_TYPE_STROBE:
+ ret = skl_int3472_register_led(int3472, gpio, "strobe", false);
if (ret)
err_msg = "Failed to register LED\n";
@@ -422,7 +434,7 @@ void int3472_discrete_cleanup(struct int3472_discrete_device *int3472)
gpiod_remove_lookup_table(&int3472->gpios);
skl_int3472_unregister_clock(int3472);
- skl_int3472_unregister_led(int3472);
+ skl_int3472_unregister_leds(int3472);
skl_int3472_unregister_regulator(int3472);
}
EXPORT_SYMBOL_NS_GPL(int3472_discrete_cleanup, "INTEL_INT3472_DISCRETE");
diff --git a/drivers/platform/x86/intel/int3472/led.c b/drivers/platform/x86/intel/int3472/led.c
index 8222550..77f61a4 100644
--- a/drivers/platform/x86/intel/int3472/led.c
+++ b/drivers/platform/x86/intel/int3472/led.c
@@ -16,15 +16,17 @@ static int int3472_led_set(struct led_classdev *led_cdev,
}
int skl_int3472_register_led(struct int3472_discrete_device *int3472,
- struct gpio_desc *gpio, const char *name)
+ struct gpio_desc *gpio, const char *name,
+ bool has_lookup)
{
- struct int3472_led *led = &int3472->led;
+ struct int3472_led *led;
char *p;
int ret;
- if (led->classdev.dev)
- return -EBUSY;
+ if (int3472->n_leds >= INT3472_MAX_LEDS)
+ return -ENOSPC;
+ led = &int3472->leds[int3472->n_leds];
led->gpio = gpio;
/* Generate the name, replacing the ':' in the ACPI devname with '_' */
@@ -42,22 +44,26 @@ int skl_int3472_register_led(struct int3472_discrete_device *int3472,
if (ret)
return ret;
- led->lookup.provider = led->name;
- led->lookup.dev_id = int3472->sensor_name;
- led->lookup.con_id = "privacy";
- led_add_lookup(&led->lookup);
+ if (has_lookup) {
+ led->lookup.provider = led->name;
+ led->lookup.dev_id = int3472->sensor_name;
+ led->lookup.con_id = name;
+ led_add_lookup(&led->lookup);
+ led->has_lookup = true;
+ }
+ int3472->n_leds++;
return 0;
}
-void skl_int3472_unregister_led(struct int3472_discrete_device *int3472)
+void skl_int3472_unregister_leds(struct int3472_discrete_device *int3472)
{
- struct int3472_led *led = &int3472->led;
+ for (unsigned int i = 0; i < int3472->n_leds; i++) {
+ struct int3472_led *led = &int3472->leds[i];
- if (IS_ERR_OR_NULL(led->classdev.dev))
- return;
-
- led_remove_lookup(&led->lookup);
- led_classdev_unregister(&led->classdev);
- gpiod_put(led->gpio);
+ if (led->has_lookup)
+ led_remove_lookup(&led->lookup);
+ led_classdev_unregister(&led->classdev);
+ gpiod_put(led->gpio);
+ }
}
diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
index 3a077f4..540e3f2 100644
--- a/include/linux/platform_data/x86/int3472.h
+++ b/include/linux/platform_data/x86/int3472.h
@@ -23,6 +23,7 @@
/* PMIC GPIO Types */
#define INT3472_GPIO_TYPE_RESET 0x00
#define INT3472_GPIO_TYPE_POWERDOWN 0x01
+#define INT3472_GPIO_TYPE_STROBE 0x02
#define INT3472_GPIO_TYPE_POWER_ENABLE 0x0b
#define INT3472_GPIO_TYPE_CLK_ENABLE 0x0c
#define INT3472_GPIO_TYPE_PRIVACY_LED 0x0d
@@ -31,6 +32,7 @@
#define INT3472_PDEV_MAX_NAME_LEN 23
#define INT3472_MAX_SENSOR_GPIOS 3
+#define INT3472_MAX_LEDS 2
#define INT3472_MAX_REGULATORS 3
/* E.g. "avdd\0" */
@@ -126,12 +128,14 @@ struct int3472_discrete_device {
struct led_lookup_data lookup;
char name[INT3472_LED_MAX_NAME_LEN];
struct gpio_desc *gpio;
- } led;
+ bool has_lookup;
+ } leds[INT3472_MAX_LEDS];
struct int3472_discrete_quirks quirks;
unsigned int ngpios; /* how many GPIOs have we seen */
unsigned int n_sensor_gpios; /* how many have we mapped to sensor */
+ unsigned int n_leds; /* how many LEDs have we registered */
unsigned int n_regulator_gpios; /* how many have we mapped to a regulator */
struct gpiod_lookup_table gpios;
};
@@ -161,7 +165,8 @@ int skl_int3472_register_regulator(struct int3472_discrete_device *int3472,
void skl_int3472_unregister_regulator(struct int3472_discrete_device *int3472);
int skl_int3472_register_led(struct int3472_discrete_device *int3472,
- struct gpio_desc *gpio, const char *name);
-void skl_int3472_unregister_led(struct int3472_discrete_device *int3472);
+ struct gpio_desc *gpio, const char *name,
+ bool has_lookup);
+void skl_int3472_unregister_leds(struct int3472_discrete_device *int3472);
#endif
--
2.47.3
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@kcore.it>
> ---
...rather somewhere here (after '---' line).
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
...
> 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
© 2016 - 2026 Red Hat, Inc.