[PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[Marco Nenciarini]

Some ACPI tables on Intel Meteor Lake and Arrow Lake platforms define
GPIO resources with type 0x02 for INT3472 camera sensor power control.
This type is not currently handled, causing a "GPIO type 0x02 unknown;
the sensor may not work" warning and preventing proper sensor power
sequencing.

Map GPIO type 0x02 (strobe) to the privacy LED handler, matching the
approach used for similar illumination-related GPIOs. This is consistent
with the original proposal by Hao Yao [1].

Tested on a Dell Pro Max 16 Premium (Arrow Lake-H) with OmniVision
OV08F4 sensor connected via Intel IPU6 and Synaptics SVP7500 USBIO
bridge. With this patch applied, the int3472-discrete driver no longer
warns about unknown GPIO type 0x02, and the sensor probes successfully.

[1] https://lore.kernel.org/all/20231007021309.9332-1-hao.yao@intel.com/

Link: https://bugs.debian.org/1130114
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2138991
Cc: Hao Yao <hao.yao@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
---
 drivers/platform/x86/intel/int3472/discrete.c | 3 +++
 include/linux/platform_data/x86/int3472.h     | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index 1505fc3..39ca60b 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -211,6 +211,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
 		*con_id = "clk-enable";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
 		break;
+	case INT3472_GPIO_TYPE_STROBE:
 	case INT3472_GPIO_TYPE_PRIVACY_LED:
 		*con_id = "privacy-led";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
@@ -330,6 +331,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
 
 		break;
 	case INT3472_GPIO_TYPE_CLK_ENABLE:
+	case INT3472_GPIO_TYPE_STROBE:
 	case INT3472_GPIO_TYPE_PRIVACY_LED:
 	case INT3472_GPIO_TYPE_POWER_ENABLE:
 	case INT3472_GPIO_TYPE_HANDSHAKE:
@@ -347,6 +349,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
 				err_msg = "Failed to register clock\n";
 
 			break;
+		case INT3472_GPIO_TYPE_STROBE:
 		case INT3472_GPIO_TYPE_PRIVACY_LED:
 			ret = skl_int3472_register_pled(int3472, gpio);
 			if (ret)
diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
index b1b8375..85adeb0 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
-- 
2.47.3

[PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[Marco Nenciarini]

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

Some ACPI tables on Intel Meteor Lake and Arrow Lake platforms define
GPIO resources with type 0x02 for INT3472 camera sensor power control.
This type is not currently handled, causing a "GPIO type 0x02 unknown;
the sensor may not work" warning and preventing proper sensor power
sequencing.

Map GPIO type 0x02 (strobe) to the privacy LED handler, matching the
approach used for similar illumination-related GPIOs. This is consistent
with the original proposal by Hao Yao [1].

Tested on a Dell Pro Max 16 Premium (Arrow Lake-H) with OmniVision
OV08F4 sensor connected via Intel IPU6 and Synaptics SVP7500 USBIO
bridge. With this patch applied, the int3472-discrete driver no longer
warns about unknown GPIO type 0x02, and the sensor probes successfully.

[1] https://lore.kernel.org/all/20231007021309.9332-1-hao.yao@intel.com/

Link: https://bugs.debian.org/1130114
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2138991
Cc: Hao Yao <hao.yao@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
---
 drivers/platform/x86/intel/int3472/discrete.c | 3 +++
 include/linux/platform_data/x86/int3472.h     | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index 1505fc3..39ca60b 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -211,6 +211,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
 		*con_id = "clk-enable";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
 		break;
+	case INT3472_GPIO_TYPE_STROBE:
 	case INT3472_GPIO_TYPE_PRIVACY_LED:
 		*con_id = "privacy-led";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
@@ -330,6 +331,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
 
 		break;
 	case INT3472_GPIO_TYPE_CLK_ENABLE:
+	case INT3472_GPIO_TYPE_STROBE:
 	case INT3472_GPIO_TYPE_PRIVACY_LED:
 	case INT3472_GPIO_TYPE_POWER_ENABLE:
 	case INT3472_GPIO_TYPE_HANDSHAKE:
@@ -347,6 +349,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
 				err_msg = "Failed to register clock\n";
 
 			break;
+		case INT3472_GPIO_TYPE_STROBE:
 		case INT3472_GPIO_TYPE_PRIVACY_LED:
 			ret = skl_int3472_register_pled(int3472, gpio);
 			if (ret)
diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
index b1b8375..85adeb0 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
-- 
2.47.3


-- 
Marco Nenciarini - mnencia@kcore.it
7C23 B804 3E65 D298 0A21  B6E2 589F 03F0 1BA5 5038

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[Andy Shevchenko]

On Fri, Mar 20, 2026 at 11:35 AM Marco Nenciarini <mnencia@kcore.it> wrote:

You sent three emails without versioning (no new versions) and no
changelog. Please, slow down with that, it's quite confusing. The
recommended period between two sequential versions is 24h+. Also see
more comments below.

> Some ACPI tables on Intel Meteor Lake and Arrow Lake platforms define
> GPIO resources with type 0x02 for INT3472 camera sensor power control.
> This type is not currently handled, causing a "GPIO type 0x02 unknown;
> the sensor may not work" warning and preventing proper sensor power
> sequencing.
>
> Map GPIO type 0x02 (strobe) to the privacy LED handler, matching the
> approach used for similar illumination-related GPIOs. This is consistent
> with the original proposal by Hao Yao [1].
>
> Tested on a Dell Pro Max 16 Premium (Arrow Lake-H) with OmniVision
> OV08F4 sensor connected via Intel IPU6 and Synaptics SVP7500 USBIO
> bridge. With this patch applied, the int3472-discrete driver no longer
> warns about unknown GPIO type 0x02, and the sensor probes successfully.

> [1] https://lore.kernel.org/all/20231007021309.9332-1-hao.yao@intel.com/

This should be a Link tag in a form

Link: ...$URL... [1]

> Link: https://bugs.debian.org/1130114
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2138991

These are basically should be Closes: tags

...

> Cc: Hao Yao <hao.yao@intel.com>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Andy Shevchenko <andy@kernel.org>

These Cc's are better to be after the '---' line below. The Git
tooling will recognize them and use them in email as intended.

> Signed-off-by: Marco Nenciarini <mnencia@kcore.it>

...

> +       case INT3472_GPIO_TYPE_STROBE:
>         case INT3472_GPIO_TYPE_PRIVACY_LED:

Hmm... But strobe is usually used for LED flash... We probably need
Sakari and/or other Intel camera guys to elaborate on this.

>                 *con_id = "privacy-led";
>                 *gpio_flags = GPIO_ACTIVE_HIGH;

...

> +               case INT3472_GPIO_TYPE_STROBE:
>                 case INT3472_GPIO_TYPE_PRIVACY_LED:
>                         ret = skl_int3472_register_pled(int3472, gpio);

Ditto.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[Andy Shevchenko]

On Fri, Mar 20, 2026 at 1:57 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Mar 20, 2026 at 11:35 AM Marco Nenciarini <mnencia@kcore.it> wrote:
>
> You sent three emails without versioning (no new versions) and no
> changelog. Please, slow down with that, it's quite confusing. The
> recommended period between two sequential versions is 24h+. Also see
> more comments below.

One more thing, this was sent to a partially correct list of
stakeholders. You need to use get_maintainer.pl to see who is required
to be notified with the proposed change. I have my "smart" script [1]
which does this for me based on some heuristic. Feel free to take and
use that.

[1]: https://github.com/andy-shev/home-bin-tools/blob/master/ge2maintainer.sh


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[Marco Nenciarini]

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

Hi Andy,

First, apologies for the triple submission. It was a sending error
on my side (mutt submitted three separate copies), not three patch
versions. Please disregard the duplicates.

Regarding your feedback:

> Link tag, Closes tags, Cc placement

Noted, thank you for the clear guidance. I will apply these if I
send an updated version.

> get_maintainer.pl

Thank you for the pointer and for sharing your ge2maintainer.sh
script.

> strobe / privacy-led mapping

Hans pointed out that GPIO type 0x02 is actually for an IR flood
LED, not a privacy LED. After digging into the ACPI tables on my
machine, I confirmed he is correct. The GPIO belongs to an INT3472
controlling an empty IR sensor slot, not the active OV08F4 camera.
I have replied to Hans with the full analysis. The mapping in this
patch is semantically wrong, so it may not be needed at all, or it
would need the refactoring Hans suggested.

Thanks,
Marco

-- 
Marco Nenciarini - mnencia@kcore.it
7C23 B804 3E65 D298 0A21  B6E2 589F 03F0 1BA5 5038

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[johannes.goede]

Hi,

On 20-Mar-26 10:34, Marco Nenciarini wrote:
> Some ACPI tables on Intel Meteor Lake and Arrow Lake platforms define
> GPIO resources with type 0x02 for INT3472 camera sensor power control.
> This type is not currently handled, causing a "GPIO type 0x02 unknown;
> the sensor may not work" warning and preventing proper sensor power
> sequencing.
> 
> Map GPIO type 0x02 (strobe) to the privacy LED handler, matching the
> approach used for similar illumination-related GPIOs. This is consistent
> with the original proposal by Hao Yao [1].
> 
> Tested on a Dell Pro Max 16 Premium (Arrow Lake-H) with OmniVision
> OV08F4 sensor connected via Intel IPU6 and Synaptics SVP7500 USBIO
> bridge. With this patch applied, the int3472-discrete driver no longer
> warns about unknown GPIO type 0x02, and the sensor probes successfully.

The strobe GPIO is typically used only for IR sensors (for Windows Hello)
and the  OV08F4 / ov08x40 is the regular color sensor.

Did you check with your latest working setup that this patch is
necessary at all ?  I would expect (other then the warning) things to
work fine without this patch, you likely have 2 INT3472 ACPI devices
and the one throwing the warning is not used for the OVTI08F4 sensor.

The GPIO with type 0x02 seems to control an IR flood LED to IR illuminate
the scene when the IR camera is on. As such mapping it as a privacy LED
is not really what we want.

Mapping it as a LED makes sense, but we should give it a different
name. So add a name parameter to skl_int3472_register_pled() and
rename the function to skl_int3472_register_led().

And then for the existing privacy LED pass: "privacy_led" as
name and for the type 0x02 GPIO pass: "ir_flood_led" as name
parameter ?

This solves things from the int3472 pov, but is not really
helpful otherwise.

Arguably we do want to turn on the ir_flood_led on streaming on
automatically like we do for the privacy LED atm. But just using
a different name gives us flexibility to allow more fine-grained
control in the future ...

Sakari any remarks from the V4L2 side here ?

Regards,

Hans




> [1] https://lore.kernel.org/all/20231007021309.9332-1-hao.yao@intel.com/
> 
> Link: https://bugs.debian.org/1130114
> Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2138991
> Cc: Hao Yao <hao.yao@intel.com>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
> ---
>  drivers/platform/x86/intel/int3472/discrete.c | 3 +++
>  include/linux/platform_data/x86/int3472.h     | 1 +
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
> index 1505fc3..39ca60b 100644
> --- a/drivers/platform/x86/intel/int3472/discrete.c
> +++ b/drivers/platform/x86/intel/int3472/discrete.c
> @@ -211,6 +211,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
>  		*con_id = "clk-enable";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
>  		break;
> +	case INT3472_GPIO_TYPE_STROBE:
>  	case INT3472_GPIO_TYPE_PRIVACY_LED:
>  		*con_id = "privacy-led";
>  		*gpio_flags = GPIO_ACTIVE_HIGH;
> @@ -330,6 +331,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
>  
>  		break;
>  	case INT3472_GPIO_TYPE_CLK_ENABLE:
> +	case INT3472_GPIO_TYPE_STROBE:
>  	case INT3472_GPIO_TYPE_PRIVACY_LED:
>  	case INT3472_GPIO_TYPE_POWER_ENABLE:
>  	case INT3472_GPIO_TYPE_HANDSHAKE:
> @@ -347,6 +349,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
>  				err_msg = "Failed to register clock\n";
>  
>  			break;
> +		case INT3472_GPIO_TYPE_STROBE:
>  		case INT3472_GPIO_TYPE_PRIVACY_LED:
>  			ret = skl_int3472_register_pled(int3472, gpio);
>  			if (ret)
> diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
> index b1b8375..85adeb0 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

Re: [PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[Marco Nenciarini]

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

Hi Hans,

Thank you for the detailed review.

You are absolutely right. I dug into the ACPI tables on my Dell Pro
Max 16 Premium (Arrow Lake-H) and found the following:

There are 19 INT3472 template devices in the DSDT, but only one is
active: DSC0 (\_SB_.PC00.DSC0, uid=0, status=15). DSC0 has two GPIO
entries:
  - GPIO entry 1: type 0x12 (HANDSHAKE), pin 1
  - GPIO entry 2: type 0x02 (STROBE), pin 48

DSC0 is paired with LNK0 (sensor slot 0), which has no active sensor
on this machine. The OV08F4 color sensor is on LNK1, which on Arrow
Lake depends on CVSS (INTC10E0, Intel CVS Device), not on any INT3472.

Three sensors are defined in ACPI:
  - OVTI08F4 on LNK1 (status=15, active) — the front-facing color camera
  - OVTI13B1 on LNK2 (status=0, disabled)
  - OVTI01AS on LNK3 (status=0, disabled) — likely the IR sensor

So the GPIO type 0x02 warning comes from an INT3472 that controls a
non-existent IR sensor slot. The warning is harmless noise in this
case and the patch is not actually needed for the OV08F4 to work.

That said, the patch (or your suggested refactoring with a proper
"ir_flood_led" name) would still clean up the warning for any system
where an IR sensor slot's INT3472 is enabled without the sensor
being present. Would it be worth pursuing as a cleanup, or is it
better to just leave the warning as-is since it correctly flags an
unconfigured GPIO?

Thanks,
Marco

-- 
Marco Nenciarini - mnencia@kcore.it
7C23 B804 3E65 D298 0A21  B6E2 589F 03F0 1BA5 5038

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH] platform/x86: int3472: Add GPIO type 0x02 (strobe) mapping

[Marco Nenciarini]

Some ACPI tables on Intel Meteor Lake and Arrow Lake platforms define
GPIO resources with type 0x02 for INT3472 camera sensor power control.
This type is not currently handled, causing a "GPIO type 0x02 unknown;
the sensor may not work" warning and preventing proper sensor power
sequencing.

Map GPIO type 0x02 (strobe) to the privacy LED handler, matching the
approach used for similar illumination-related GPIOs. This is consistent
with the original proposal by Hao Yao [1].

Tested on a Dell Pro Max 16 Premium (Arrow Lake-H) with OmniVision
OV08F4 sensor connected via Intel IPU6 and Synaptics SVP7500 USBIO
bridge. With this patch applied, the int3472-discrete driver no longer
warns about unknown GPIO type 0x02, and the sensor probes successfully.

[1] https://lore.kernel.org/all/20231007021309.9332-1-hao.yao@intel.com/

Link: https://bugs.debian.org/1130114
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2138991
Cc: Hao Yao <hao.yao@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
---
 drivers/platform/x86/intel/int3472/discrete.c | 3 +++
 include/linux/platform_data/x86/int3472.h     | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c
index 1505fc3..39ca60b 100644
--- a/drivers/platform/x86/intel/int3472/discrete.c
+++ b/drivers/platform/x86/intel/int3472/discrete.c
@@ -211,6 +211,7 @@ static void int3472_get_con_id_and_polarity(struct int3472_discrete_device *int3
 		*con_id = "clk-enable";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
 		break;
+	case INT3472_GPIO_TYPE_STROBE:
 	case INT3472_GPIO_TYPE_PRIVACY_LED:
 		*con_id = "privacy-led";
 		*gpio_flags = GPIO_ACTIVE_HIGH;
@@ -330,6 +331,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
 
 		break;
 	case INT3472_GPIO_TYPE_CLK_ENABLE:
+	case INT3472_GPIO_TYPE_STROBE:
 	case INT3472_GPIO_TYPE_PRIVACY_LED:
 	case INT3472_GPIO_TYPE_POWER_ENABLE:
 	case INT3472_GPIO_TYPE_HANDSHAKE:
@@ -347,6 +349,7 @@ static int skl_int3472_handle_gpio_resources(struct acpi_resource *ares,
 				err_msg = "Failed to register clock\n";
 
 			break;
+		case INT3472_GPIO_TYPE_STROBE:
 		case INT3472_GPIO_TYPE_PRIVACY_LED:
 			ret = skl_int3472_register_pled(int3472, gpio);
 			if (ret)
diff --git a/include/linux/platform_data/x86/int3472.h b/include/linux/platform_data/x86/int3472.h
index b1b8375..85adeb0 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
-- 
2.47.3