Re: [BUG] OV02C10 on Dell 16 Premium DA16250 (ARL): INT3472 handshake-derived "dvdd" regulator registered but never linked to sensor, sensor probe fails with -EREMOTEIO

[Marco Nenciarini <mnencia@kcore.it>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEfCO4BD5l0pgKIbbiWJ8D8BulUDgFAmof1vIACgkQWJ8D8Bul
UDhKsxAAhvXDzdrZLmLC+7kV5ORVVl0oEZxv/ylThq8xzkiPdkkkdCYcf0cF/Xgp
rH2LvTr/lqJjCL8P8S7ytzJ+8DCX7UpjnFy5AsyTJZGBa312eG9Ksrf9GMOJ5slL
r4KqKu8feyuQNgkaYKsxO342OSlPas5aAKVUIQeEUB+1Q2eQ4ffe5MR+Rdub9a5q
1SKIfmuAzs7DJc86gBYmA6wz7FEpmXNH3ugu3QLFLB7NlEQEHQIl8Jo3w5yt5GCi
Gs+0JgmydKkTmNpUJ4c13tXk+G3G8Um2fg6sgwIX/pOhjbPrrzpgZgwVGI/eZdfM
MKQ2qWYiMuDFsd3ZnXMyHrffIVMj2q/UB+ye2bAP3a9QsxubuvCaCGk+ksBRvtUk
4GE1MQ+yFVakru93ADfTJ+ASuyaVI6fVG9H4zt46up5z04DzGYSYhXAJSOfBCz6A
CRAkKBkTga8bHeqdt289kzgES+OIkX2XeE7eOl8JX+LoDIfQiLD7cbGynHNjR4mf
fjfBVwTmwRES+KC5+KLbsgrdCfpX0RCb8iBmQto7jxTUImKI3xMgmHYf51PYyqmA
/uSpYW1G4YwBGn8/9aI2P9FiQyQXdt6LTqBz+Ld9CxGiKUNvfj078lcZoa7Dq22n
5S14yapsNfoJbEyYhIshu2exu9rcW30DGSnloS1gTuIvz+e72hc=
=egB7
-----END PGP SIGNATURE-----