[BUG] platform/x86: int3472/discrete: unknown GPIO type 0x08 breaks OV13858 rear camera on Surface Pro 11/12 Business (INT3472:00 / OVTID858)

[BUG] platform/x86: int3472/discrete: unknown GPIO type 0x08 breaks OV13858 rear camera on Surface Pro 11/12 Business (INT3472:00 / OVTID858)

[German]

Hi,

On the Microsoft Surface Pro 11/12 Business (Intel Lunar Lake, IPU7),
the rear camera sensor (ov13858, ACPI HID OVTID858) fails to probe.
I've traced the root cause to int3472-discrete not recognizing one of
the GPIO types described in the device's ACPI _DSM data, which leaves
a power/reset-related GPIO unconfigured and the sensor unable to
respond over I2C.

System
------
- Surface Pro for Business 11th Edition with Intel (Intel Lunar Lake, IPU7)
- Kernel: 7.2.2 (Arch Linux, vanilla)
- CONFIG_VIDEO_OV13858=m

Evidence
--------

  $ dmesg | grep -iE "int3472|OVTID858"
  [    5.555231] int3472-discrete INT3472:00: GPIO type 0x08 unknown; the sensor may not work
  [    5.788882] ov13858 i2c-OVTID858:00: failed to find sensor: -5
  [    5.789321] ov13858 i2c-OVTID858:00: probe with driver ov13858 failed with error -5

The "GPIO type 0x08 unknown" warning comes from the default case in
skl_int3472_handle_gpio_resources() in drivers/platform/x86/intel/
int3472/discrete.c:

    default:
        dev_warn(int3472->dev,
                 "GPIO type 0x%02x unknown; the sensor may not work\n",
                 type);
        ret = 1;
        break;

~230ms later, ov13858_probe() fails in ov13858_identify_module()
with -EIO (-5) while trying to read the sensor's chip ID register
over I2C - consistent with the sensor not being properly powered/
reset because one of its GPIOs was left unconfigured.

The currently known/handled GPIO types in common.h are:

    INT3472_GPIO_TYPE_RESET        0x00
    INT3472_GPIO_TYPE_POWERDOWN    0x01
    INT3472_GPIO_TYPE_POWER_ENABLE 0x0b
    INT3472_GPIO_TYPE_CLK_ENABLE   0x0c
    INT3472_GPIO_TYPE_PRIVACY_LED  0x0d
    INT3472_GPIO_TYPE_HANDSHAKE    0x12
    INT3472_GPIO_TYPE_HOTPLUG_DETECT 0x13
    (plus DOVDD/STROBE in newer trees)

0x08 does not correspond to any of these, so it's silently skipped
and the sensor is left without whatever line that pin controls.

This is not a boot-time race: I tried unbinding and rebinding the
ov13858 i2c driver well after boot had fully settled, and the probe
fails identically both times, at very different uptimes:

  $ echo "i2c-OVTID858:00" | sudo tee /sys/bus/i2c/drivers/ov13858/unbind
  $ echo "i2c-OVTID858:00" | sudo tee /sys/bus/i2c/drivers/ov13858/bind
  [  470.046844] ov13858 i2c-OVTID858:00: failed to find sensor: -5
  [  470.046855] ov13858 i2c-OVTID858:00: probe with driver ov13858 failed with error -5
  ...
  [  703.417136] ov13858 i2c-OVTID858:00: failed to find sensor: -5
  [  703.417153] ov13858 i2c-OVTID858:00: probe with driver ov13858 failed with error -5

This rules out a probe-ordering/deferral issue and points at a
persistent hardware-configuration gap: whatever pin type 0x08
represents on this board is never toggled/configured, so the sensor
stays in a bad power/reset state indefinitely.

Possible precedent
-------------------
I noticed drivers/platform/x86/intel/int3472/discrete.c already has a
per-ACPI-HID quirk table (int3472_gpio_map[]) for exactly this kind
of situation - e.g. OVTI08F4 (ov08x40) needed its GPIO type remapped
to INT3472_GPIO_TYPE_HANDSHAKE with a 45ms enable delay on some HP
laptops. It's possible OVTID858 on this Surface board needs a similar
per-HID quirk entry mapping type 0x08 to one of the existing known
types (my guess, unverified, would be a reset/powerdown-adjacent
line, given the symptom - sensor unreachable over I2C at all times,
not just during a specific mode), but I don't have visibility into
what the ACPI _DSM on this board actually intends by 0x08, so I'd
rather report this precisely and let someone with more context
(and/or ACPI table access) confirm than guess further.

Happy to pull the full DSDT/SSDT for the INT3472 device, run with
dynamic_debug enabled on int3472-discrete, or test any proposed
patch on real hardware - just let me know what would help.

Thanks,
[TODO: German]
[TODO: germanpapulindez@gmail.com]

Re: [BUG] platform/x86: int3472/discrete: unknown GPIO type 0x08 breaks OV13858 rear camera on Surface Pro 11/12 Business (INT3472:00 / OVTID858)

[Sakari Ailus]

Hi German,

On Thu, Sep 03, 2026 at 10:15:56AM +0200, German wrote:
> Hi,
> 
> On the Microsoft Surface Pro 11/12 Business (Intel Lunar Lake, IPU7),
> the rear camera sensor (ov13858, ACPI HID OVTID858) fails to probe.
> I've traced the root cause to int3472-discrete not recognizing one of
> the GPIO types described in the device's ACPI _DSM data, which leaves
> a power/reset-related GPIO unconfigured and the sensor unable to
> respond over I2C.
> 
> System
> ------
> - Surface Pro for Business 11th Edition with Intel (Intel Lunar Lake, IPU7)
> - Kernel: 7.2.2 (Arch Linux, vanilla)

It's usually best to test with linux-next, not with distro kernels, or in
this case, the media committers tree
<URL:https://gitlab.freedesktop.org/linux-media/media-committers> next
branch.

> - CONFIG_VIDEO_OV13858=m
> 
> Evidence
> --------
> 
>   $ dmesg | grep -iE "int3472|OVTID858"
>   [    5.555231] int3472-discrete INT3472:00: GPIO type 0x08 unknown; the sensor may not work
>   [    5.788882] ov13858 i2c-OVTID858:00: failed to find sensor: -5
>   [    5.789321] ov13858 i2c-OVTID858:00: probe with driver ov13858 failed with error -5
> 
> The "GPIO type 0x08 unknown" warning comes from the default case in
> skl_int3472_handle_gpio_resources() in drivers/platform/x86/intel/
> int3472/discrete.c:
> 
>     default:
>         dev_warn(int3472->dev,
>                  "GPIO type 0x%02x unknown; the sensor may not work\n",
>                  type);
>         ret = 1;
>         break;

This should be addressed by commit 34e31390a3b939db2e0cbfef4c40d95052572df0
.

-- 
Regards,

Sakari Ailus

Re: [BUG] platform/x86: int3472/discrete: unknown GPIO type 0x08 breaks OV13858 rear camera on Surface Pro 11/12 Business (INT3472:00 / OVTID858)

[Andy Shevchenko]

On Thu, Sep 3, 2026 at 11:26 AM Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
> On Thu, Sep 03, 2026 at 10:15:56AM +0200, German wrote:

> > On the Microsoft Surface Pro 11/12 Business (Intel Lunar Lake, IPU7),
> > the rear camera sensor (ov13858, ACPI HID OVTID858) fails to probe.
> > I've traced the root cause to int3472-discrete not recognizing one of
> > the GPIO types described in the device's ACPI _DSM data, which leaves
> > a power/reset-related GPIO unconfigured and the sensor unable to
> > respond over I2C.
> >
> > System
> > ------
> > - Surface Pro for Business 11th Edition with Intel (Intel Lunar Lake, IPU7)
> > - Kernel: 7.2.2 (Arch Linux, vanilla)
>
> It's usually best to test with linux-next, not with distro kernels, or in
> this case, the media committers tree
> <URL:https://gitlab.freedesktop.org/linux-media/media-committers> next
> branch.
>
> > - CONFIG_VIDEO_OV13858=m
> >
> > Evidence
> > --------
> >
> >   $ dmesg | grep -iE "int3472|OVTID858"
> >   [    5.555231] int3472-discrete INT3472:00: GPIO type 0x08 unknown; the sensor may not work
> >   [    5.788882] ov13858 i2c-OVTID858:00: failed to find sensor: -5
> >   [    5.789321] ov13858 i2c-OVTID858:00: probe with driver ov13858 failed with error -5
> >
> > The "GPIO type 0x08 unknown" warning comes from the default case in
> > skl_int3472_handle_gpio_resources() in drivers/platform/x86/intel/
> > int3472/discrete.c:
> >
> >     default:
> >         dev_warn(int3472->dev,
> >                  "GPIO type 0x%02x unknown; the sensor may not work\n",
> >                  type);
> >         ret = 1;
> >         break;
>
> This should be addressed by commit 34e31390a3b939db2e0cbfef4c40d95052572df0
> .

I can't see that commit in many trees from kernel.org nor in
media.git. So, you mean it *will* be in Linux Next soon.

-- 
With Best Regards,
Andy Shevchenko