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

[Hans de Goede <hansg@kernel.org>]

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
>