Surface Pro 7+ here (Fedora 44, kernel 6.19.8-3.surface.fc43, IPU6 8086:9a19). I hit
this exact failure and fixed it independently, from the firmware side rather than the
driver side, and I think the comparison is worth having on this thread before the patch
goes anywhere upstream.

Same fault, confirmed

ov8865 i2c-INT347A:00: supply dvdd not found, using dummy regulator
ov8865 i2c-INT347A:00: supply dovdd not found, using dummy regulator
int3472-discrete INT3472:01: GPIO type 0x08 detected on pin 0xaf
int3472-discrete INT3472:01:   con_id=pwr1, flags=0x0
ov8865 i2c-INT347A:00: failed to perform sw reset
ov8865 i2c-INT347A:00: Error -121 runtime-resuming sensor, cannot instantiate VCM

regulator.2  name=INT3472:01-avdd  state=disabled  users=0
regulator.3  name=INT3472:01-pwr1  state=disabled  users=0

I also pinned down which pin it is. Sweeping GPIO state across an unbind/bind cycle of
the ov8865 driver, so the whole power-up sequence runs from scratch:

So the rail exists, is registered, and is never enabled — because it is registered under a
name nothing asks for. That matches your diagnosis exactly.

What pwr1 actually is

pwr1 is not a name that comes from anywhere authoritative. It is introduced by this
tree's 0013-cameras.patch:

case 0x08:  /* Surface Pro 9 - additional power rail */
    *con_id = "pwr1";

I checked what mainline does with type 0x08 by disassembling
int3472_get_con_id_and_polarity in both modules installed on this machine and following
the relocations into .rodata:

Mainline does not handle type 0x08 at all. The pwr1 name exists only here, and it
was introduced as an explicit guess for a type nobody had identified — the original comment
speculates it could be a focus motor or a flash.

That is why I think the patch as written cannot go upstream: it teaches a mainline sensor
driver to request a supply name that only exists in an out-of-tree patch. From mainline's
point of view ov8865 would be asking for a rail that never appears.

What the pin is

It is DVDD. I verified this by patching the DSDT so that INT3472:01's _DSM declares the
pin as type 0x12 instead of 0x08 — one byte, verified at ASL level — and booting with
the patched table:

int3472-discrete INT3472:01: GPIO type 0x12 detected on pin 0xaf
regulator name=INT3472:01-dvdd
ov8865 i2c-INT347A:00: Instantiated dw9719 VCM

3264x2448-SBGGR10/RAW   15 fps    10/10 frames
1280x720-ABGR8888/sRGB  30 fps    30/30 frames

Both original I2C errors are gone. The control is that the front ov5693 on the same
machine still complains about its own two supplies in that same boot, so this is not a
"something else changed" result. The front camera also needs the MIPI_CTRL00 write from
#2171 — same as you reported.

Suggested alternative: map it, don't rename it

Since the pin is DVDD, the smallest correct fix is to map the firmware's type to a type
the driver already understands, keyed on the sensor HID — which is exactly how the ov08x40
handshake pin is already handled in int3472_gpio_map[]:

{	/* Surface Pro 7+ declares the ov8865 dvdd pin as type 0x08 */
	.hid = "INT347A",
	.type_from = 0x08,
	.type_to = INT3472_GPIO_TYPE_HANDSHAKE,
	.con_id = "dvdd",
	.enable_time_us = GPIO_REGULATOR_ENABLE_TIME,
},

Advantages over renaming in the sensor driver:

• No change to ov8865.c, so nothing depends on an out-of-tree supply name.
• The map runs before the switch, so type becomes HANDSHAKE and the existing
  regulator path handles it — the case 0x08: additions in 0013-cameras.patch are not
  needed for this sensor.
• HID-keyed, so the Pro 9 (OVTI5693 / OVTID858) is untouched.
• There is precedent for both halves: OVTI08F4 maps a pin to dvdd, and INT347E
  remaps a reset GPIO's meaning per device.

What I have and have not tested, stated plainly: I have measured that giving this pin
to the sensor as dvdd makes the camera work — via the DSDT override, on this machine.
I have not yet booted without the override with only the map entry applied, so the map
entry itself is untested in that form. I'm working on that and will report back either way.

Related: on this machine INT3472:02 (the ov7251 IR sensor, INT347E:00) registers no
GPIOs at all — not a mis-typed one, none. That is a different and earlier failure than
the rear camera's, in case anyone is looking at IR.