int3472: unhandled GPIO type 0x08 leaves the rear camera dead (Surface Pro 11, Intel)

[Sergey Lebedev]

Hello,

On a Microsoft Surface Pro 11 for Business (Intel, Lunar Lake) the rear
camera does not work, and it traces to a single unhandled GPIO type in
int3472-discrete.

  int3472-discrete INT3472:00: GPIO type 0x08 unknown;
    the sensor may not work
  ov13858 i2c-OVTID858:00: failed to find sensor: -5
  ov13858 i2c-OVTID858:00: probe with driver ov13858 failed with error -5

The result is 32 /dev/video* nodes and a media graph with zero entities.
The IPU7 itself is healthy - firmware loads, CSE authenticates, the device
reaches secure mode - so the failure is entirely on the sensor-power side.

Reproduced on 6.17, 7.0.0-28 and 7.0.0-30 (Ubuntu 26.04), and the switch
in drivers/platform/x86/intel/int3472/discrete.c still has no case for
0x08 in 7.1.0-rc7, so I do not believe this is already fixed.

What the firmware describes
---------------------------

The DSDT declares three INT3472 devices. Decoding their _DSM returns with
the driver's own field layout (type = bits 7:0, pin = bits 15:8):

  Device (ICL0)  -> INT3472:00, the rear sensor (OVTID858 / ov13858)
    0x1000070B   type 0x0b POWER_ENABLE   pin  7
    0x10000500   type 0x00 RESET          pin  5
    0x1000060D   type 0x0d PRIVACY_LED    pin  6
    0x10000408   type 0x08 <unknown>      pin  4    <- refused

  Device (ICL1)
    0x1000200B   type 0x0b POWER_ENABLE   pin 32
    0x10000810   type 0x10 DOVDD          pin  8
    0x10000900   type 0x00 RESET          pin  9
    0x10000A0D   type 0x0d PRIVACY_LED    pin 10

  Device (ICL2)
    0x1000170B   type 0x0b POWER_ENABLE   pin 23
    0x10001600   type 0x00 RESET          pin 22
    0x1000250D   type 0x0d PRIVACY_LED    pin 37

ICL0 is the only one of the three that declares a fourth GPIO, it is the
only one carrying type 0x08, and it is the one whose sensor fails. I would
not claim that proves causation - the driver returns 1 for the unknown
type and carries on, so POWER_ENABLE, RESET and PRIVACY_LED are all still
registered - but it is the only resource the kernel declines on this
machine, and the sensor then does not answer on I2C.

The question
------------

What is type 0x08 meant to be, and should discrete.c handle it? If it is
another regulator - the shape of ICL1's DOVDD entry suggests the encoding
supports several - then adding it may be all this machine needs. If it is
something else, I am happy to be told what and to test whatever you would
like tried.

I have not sent a patch because I would only be guessing at the semantics,
and guessing wrong here means silently powering a sensor rail for the wrong
reason.

What I can provide
------------------

  - full acpidump / disassembled DSDT for this machine
  - any debug patch or instrumented build you would like run; the machine
    is available and I can rebuild and boot kernels on it
  - dmesg at any log level

Two adjacent facts, in case they matter, though I am not asking for
anything about them here: the front (SONY0681) and IR (SMO55F0) sensors
have no in-tree driver bound at all, and intel_ipu7_isys still announces
itself as a staging module.

  Machine: Microsoft Surface Pro 11 for Business (Intel Core Ultra 7 268V)
  DMI SKU: Surface_Pro_11th_Edition_With_Intel_For_Business_2103
  Firmware: UEFI 17.100.143 (2025-11-19)
  Kernel:   7.0.0-30-generic, Ubuntu 26.04.1 LTS

Thanks,
Sergey Lebedev