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

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

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

[Sergey Lebedev]

Following up on my own report from this morning, because I should have
found this first: the question I asked has already been answered in
public, on a sibling machine, with patches.

  https://github.com/linux-surface/linux-surface/issues/2153

djmulder worked out the Surface Pro 10 rear camera - the same OV13858
behind the same OVTID858 ACPI id - and identified GPIO type 0x08 as
DVDD, a second digital power rail, mapped as con_id "dvdd2". They also
found three causes my report did not mention at all, because I had not
looked:

  - drivers/media/pci/intel/ipu-bridge.c has no entry for OVTID858, so the IPU
    never recognises the sensor even once it is powered
  - ov13858 never requests or releases the reset GPIO; the sensor is held in
    reset by the INT3472 and answers on I2C as soon as it is let go
  - INT3472_MAX_SENSOR_GPIOS is 3, and the _DSM here declares four, so the
    fourth would be refused by the array bound even with 0x08 understood

So please do not spend time re-deriving any of that on my account. My
apologies for the noise; I searched the kernel history and MAINTAINERS
before writing, but not the place where Surface owners actually work on
Surface hardware, which is the obvious first place to look and is entirely
my error.

What I think is still open, and what I can usefully do:

None of it has been confirmed on the Surface Pro 11, and the two machines
are not identical. On SP10 the 0x08 GPIO sits at pin 0xC6; on this SP11 it
is at pin 4, with the whole ICL0 descriptor set at different pins. The
thread also notes the two models use different sensor clock rates.

I will apply those four patches here, report back whether they are
sufficient on SP11 unchanged, and say plainly where they are not.

That thread describes its own CLK_IS_CRITICAL and always_on regulator
constraints as too broad for upstream. If you would rather see a different
shape tested - a DMI quirk, or teaching ov13858 to request its own
regulators and clock - say which and I will try it here. The machine is
available and I can build and boot kernels on it.

Thanks,
Sergey

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

[Hans de Goede]

Hi,

On 30-Aug-26 13:27, Sergey Lebedev wrote:
> 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

There already is a patch which should fix this on the list:

https://lore.kernel.org/platform-driver-x86/20260829-sp7plus-int3472-v3-1-454b50485ce2@berg.pm/

Regards,

Hans



> 
> 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
>