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

[German <germanpapulindez@gmail.com>]

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]