Hi Marco,

Sorry for the slow reply - I was away from the office until the 10th.

regulator_summary settles it - this is a missing consumer map, not an
ordering race.

INT3472:0c = \_SB.PC00.DSC0. Its _DEP is only the bridge gpiochip:

   Name (_DEP, Package (){ ^XHCI.RHUB.HS09.VGPO })

so it defers ~28 times (t=5.816..6.127) until INTC10B2:00 appears
(t=6.135), then binds. Its _DSM (79234640-9e10-4fea-a5c1-b5aa8b19756f),
decoded with TYPE=[7:0], PIN=[15:8], SENSOR_ON=[31:24]:

   func 2 -> 0x01000112  type 0x12 (handshake), pin 1, on=1  -> dvdd
   func 3 -> 0x01000002  type 0x02 (strobe),    pin 0, on=1  -> IR flood

The dvdd GPIO (func 2) is handled before the strobe (func 3), so it is
already processed by the time the "GPIO type 0x02 unknown" warning
fires at t=6.143.

regulator_summary shows the result:

   INT3472:0c-dvdd    0   0   0   unknown   0mV ...   (use=0 open=0)

The dvdd regulator IS registered, but with zero consumers - no supply
map to i2c-OVTI02C1:00 was ever created. So when ov02c10 probes at
t=6.468 (0.32s AFTER INT3472:0c bound and after the dvdd GPIO was
handled), regulator_get(dvdd) returns -ENODEV regardless of timing:

   [6.468] ov02c10 i2c-OVTI02C1:00: supply dvdd not found, using dummy 
regulator
   [6.471] ov02c10 i2c-OVTI02C1:00: Error reading reg 0x300a: -121
   [6.471] ov02c10 ... probe with driver ov02c10 failed with error -121

The dummy enable is a no-op, the rail stays down, the 0x300a read
fails -EREMOTEIO, and that hard error is never retried.

This means the handshake-derived regulator path registers the provider
without planting the consumer supply map the way the GPIO power-enable
path does in skl_int3472_register_regulator(). Adding that map
(dev_name "i2c-OVTI02C1:00", supply "dvdd") for the handshake type
should be enough; an -EPROBE_DEFER "supply coming later" signal would
not help here since the map is never created at all.

For completeness on the ordering side: LNK1's _DEP never references
DSC0 in any branch (ARLP -> {CVSS, HS09.VIC1}; non-ARLP -> {DSC1,
HS09.VIC1}), so there is also no serialization between DSC0 and the
sensor - but that is moot given the map is absent.

Tested on 7.0.10-1-MANJARO. Attached: decompiled
LNK1/DSC0 blocks, timestamped dmesg, and regulator_summary. Full 
acpidump available on request (zip 1Mb).

Thanks,
Samuele

Il 03/06/26 09:26, Marco Nenciarini ha scritto:
> Hi Samuele,
> 
> Thanks for the thorough report, the dmesg and the detail you included
> made this easy to trace.
> 
> Both of your hypotheses turn out not to be the mechanism. The naming is
> fine and the fwnode path is not shadowing anything. The dummy dvdd in
> your log is real and is the key clue, but the interesting question is
> how the sensor reached a regulator_get for dvdd at all.
> 
>> (a) fwnode/of-based supply matching in the regulator core now takes
>> precedence over the legacy dev_name-based supply_map lookups
> 
> It does not shadow it. regulator_dev_lookup() tries the DT/fwnode path
> first, but regulator_dt_lookup() only does anything when
> dev_of_node(dev) is non-NULL. On ACPI there is no of_node, so it
> returns NULL and the function falls through to the legacy
> regulator_map_list walk. A software_node sensor with no regulator
> phandle is therefore fine, provided the map entry exists at lookup
> time.
> 
>> (b) The sensor i2c_client created via ipu-bridge has a slightly
>> different dev_name
> 
> It does not. int3472->sensor_name is built as "i2c-" +
> acpi_dev_name(sensor), i.e. "i2c-OVTI02C1:00", and that exact string
> is planted into supply_map[].dev_name in
> skl_int3472_register_regulator(). ACPI-enumerated i2c clients are named
> the same way (dev_set_name(&client->dev, "i2c-%s", acpi_dev_name(adev))),
> so the consumer dev_name is byte-identical. No mismatch.
> 
> What the log actually tells us. The line
> 
>    ov02c10 i2c-OVTI02C1:00: supply dvdd not found, using dummy regulator
> 
> is emitted from a single site in _regulator_get_common(), on the
> have_full_constraints() == true, NORMAL_GET path, and only after the
> dummy_regulator_rdev existence check. So it means precisely this: at
> the instant ov02c10 called devm_regulator_bulk_get(), the lookup for
> "i2c-OVTI02C1:00"/dvdd returned -ENODEV, i.e. no INT3472:0c-dvdd
> consumer map entry existed yet. int3472 publishes that map while
> registering the regulator, during its own probe, and its whole probe
> defers (the ~30 retries in your log) until the USB-IO bridge gpiochip
> appears, because the dvdd HANDSHAKE GPIO lives on that chip. So
> ov02c10 took a dummy dvdd before int3472 had registered the real one.
> Under NORMAL_GET with full constraints that dummy is permanent, the
> no-op enable leaves the rail unpowered, and the 0x300a read fails
> with -EREMOTEIO, a hard error that is not placed on the deferred-probe
> list and so is never retried when the real regulator appears later. It
> is also consistent with regulator_summary showing INT3472:0c-dvdd with
> no children after the fact.
> 
> (avdd and dovdd also fall back to dummies. If those rails are
> always-on in hardware that is probably benign. dvdd is the one
> INT3472:0c is meant to gate through the handshake pin, so that is the
> one that matters here.)
> 
> Here is the part that needs your input, because it should not be
> possible. INT3472 is in acpi_honor_dep_ids, so a sensor whose _DEP
> references the INT3472 device is held out of enumeration entirely
> (acpi_dev_ready_for_enumeration() returns false, the i2c client is not
> even created) until int3472 clears the dependency. int3472-discrete
> clears it with acpi_dev_clear_dependencies() as the last step of its
> probe, after int3472_discrete_parse_crs() has registered every
> regulator including dvdd. So in the normal flow, by the time OVTI02C1
> can be enumerated at all, the dvdd map is already published and the
> sensor binds the real rail. The fact that you got a dummy means that
> gate did not serialize them on this board.
> 
> The most likely explanation is that OVTI02C1's _DEP does not carry an
> honored dependency on the INT3472:0c instance that registers dvdd (or
> there is more than one INT3472 instance and the depended-on one is not
> the dvdd provider). To confirm, could you send:
> 
>    - the OVTI02C1 _DEP (an acpidump or DSDT extract), so we can see
>      whether INT3472:0c is actually listed;
>    - a dmesg with timestamps showing the order of the int3472-discrete
>      bind, the i2c-OVTI02C1:00 device creation, and the dummy-regulator
>      warning;
>    - the INT3472:0c _CRS plus the _DSM result for the GPIO at
>      \_SB.PC00.XHCI.RHUB.HS09.VGPO pin 1, as you offered.
> 
> Hans, Sakari, this is where I would like your read. If the _DEP on
> this board is indeed missing the INT3472:0c instance, is the right fix
> a board quirk, or is it worth giving the ACPI consumer path a "supply
> coming later" signal the way the DT path has one?
> of_regulator_dev_lookup() returns -EPROBE_DEFER when the phandle
> target is not registered yet; the legacy consumer_supplies/dev_name
> map has no equivalent, so once the _DEP gate is out of the picture
> there is nothing left to make the sensor wait.
> 
> Thanks,
> Marco