Re: [PATCH v3] platform/x86: int3472: support the POWER1 GPIO type

[Sergey Lebedev <lsa.uz@pm.me>]

Hans pointed me at this from a report I sent this morning about the same
GPIO type on a Surface Pro 11 - thank you, and sorry for the duplicate
question. I have now tested this patch on that machine, which is a third
model and, more usefully, a different sensor. Result below, with the part
that is still missing for this sensor family.

Tested-by: Sergey Lebedev <lsa.uz@pm.me>   # Surface Pro 11, INT3472 side

What the patch fixes here
-------------------------

Built on 7.0.0-30 (Ubuntu 26.04). The warning is gone and the rail is
mapped:

  before: int3472-discrete INT3472:00: GPIO type 0x08 unknown;
                                       the sensor may not work
  after : no int3472 messages at all

  /sys/class/regulator:
    regulator.1  INT3472:00-avdd
    regulator.2  INT3472:00-dvdd     <- new, from this patch
    regulator.3  INT3472:01-avdd
    regulator.4  INT3472:01-dovdd
    regulator.5  INT3472:02-avdd

Nothing else regressed: audio, Secure Boot and module signing unaffected,
no failed units.

What it does not fix, and why that is not this patch's fault
------------------------------------------------------------

The camera is exactly as dead as before:

  ov13858 i2c-OVTID858:00: failed to find sensor: -5
  every regulator: num_users=0, state=disabled
  /dev/media0: 0 entities

The rear sensor here is an OV13858, and the in-tree ov13858 driver requests
no regulators and touches no GPIOs at all - zero `regulator` and zero
`gpiod` references in drivers/media/i2c/ov13858.c. So INT3472:00-dvdd is
registered and then never claimed by anyone, and the sensor is still held
in reset because nothing releases it.

That is exactly the difference between your machine and this one. ov8865
asks for "dvdd", "dovdd" and "avdd" by name, so mapping POWER1 to "dvdd"
completes the picture for the Surface Pro 7+. ov13858 asks for nothing.

The same conclusion was reached independently on the Surface Pro 10, which
carries the same OV13858:

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

There they had to add reset-GPIO handling to ov13858_probe() and force the
regulators on, and describe the latter as too broad for upstream.

So: this patch is correct and necessary, and for the OV13858 machines it is
not sufficient. The remaining work is in the sensor driver rather than in
int3472, which seems worth stating explicitly so nobody expects the Pro 10
or Pro 11 rear camera to start working when this lands.

If it would help, I am happy to test a patch teaching ov13858 to request
its supplies and release reset - it is the same shape as what ov8865
already does. The machine is here and I can build and boot kernels on it.

One note for anyone reproducing this out-of-tree: the module build uses
/usr/src/linux-headers-<ver>/include/, not the patched source tree, so
patching only the tree gives 'INT3472_GPIO_TYPE_POWER1' undeclared. The
installed header has to be patched too.

Thanks,
Sergey