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,

No problem on the timing, and thanks. The regulator_summary plus the
_DEP decode settle it, and they confirm the multi-instance hypothesis
from my last mail rather than the missing-map one.

One correction on the code side first, because it matters for the fix.
The handshake path is not missing the consumer-map step. HANDSHAKE
(type 0x12) and POWER_ENABLE (0x0b) fall through to the same call site
in skl_int3472_handle_gpio_resources(), so both go through
skl_int3472_register_regulator(), which plants supply_map[] (dev_name +
supply, lower- and upper-case) the same way for either type. That has
been the case since v6.16 (c5d039327204, "int3472: Add handshake pin
support"), so your 7.0.10 kernel has it. The dvdd map does get created.
The problem is the dev_name it is keyed on.

That dev_name is int3472->sensor_name, and sensor_name is
"i2c-" + acpi_dev_name(acpi_dev_get_next_consumer_dev(adev)), i.e. the
first device that lists the registering INT3472 instance in its _DEP.
Here that instance is INT3472:0c = DSC0 (the regulator name in your
summary, "INT3472:0c-dvdd", is built from acpi_dev_name(adev), so the
provider is unambiguously DSC0). But your _DEP decode shows the sensor
(LNK1) depends on DSC1, never on DSC0: ARLP -> {CVSS, HS09.VIC1},
non-ARLP -> {DSC1, HS09.VIC1}. So DSC0's reverse-_DEP walk does not
return OVTI02C1. It returns whatever else declares a _DEP on DSC0
(plausibly the IR-flood side, given func 3 sits on the same device),
the dvdd map is keyed to that name, and the sensor's
regulator_get("dvdd") for "i2c-OVTI02C1:00" never matches. -ENODEV,
permanent dummy under full constraints (the legacy ACPI dev_name path
has no "coming later" signal, so it is a dummy, not -EPROBE_DEFER),
rail stays down, 0x300a reads -EREMOTEIO, no retry. That is exactly the
regulator_summary you captured: INT3472:0c-dvdd registered, use=0.

Note this is specific to dvdd. DSC0's _DSM only exposes the dvdd
handshake (func 2) and the IR-flood strobe (func 3); it does not
provide avdd or dovdd. The sensor correctly _DEPs on DSC1 and is served
by DSC1 for the rails and resets DSC1 owns, which is why it gets far
enough to attempt the chip-ID read at all. dvdd is the one rail
stranded on an instance the sensor does not depend on. (avdd and dovdd
landing on dummies is most likely the always-on-rail case I mentioned
before, benign, unless you can see a gating GPIO for them on either
instance.)

Timing is not the mechanism either way. Your own timestamps already
show the sensor's get at 6.468 well after DSC0 bound at 6.135, and even
a perfectly ordered probe would still miss, because the map is keyed to
the wrong device, not registered late.

So this is a firmware _DEP-topology issue: dvdd is gated by DSC0, but
the sensor is pointed at DSC1, and nothing connects the two. Could you
confirm the two halves of that, so we are not inferring DSC0's consumer:

  - with int3472 dynamic debug on
    (dyndbg="module intel_skl_int3472_discrete +p"), the "Sensor name
    %s" line from DSC0's probe shows which device its consumer walk
    actually resolved to. If that is not OVTI02C1:00, it nails the
    keying;
  - the reverse _DEP, i.e. which device(s) list \_SB.PC00.DSC0 in their
    own _DEP (a grep of the DSDT _DEP packages). DSC0 bound rather than
    failing with "INT3472 seems to have no dependents", so something
    does depend on it; identifying it tells us where dvdd actually went.

Hans, Sakari, once that "Sensor name" line confirms DSC0 is keying its
dvdd to a non-sensor consumer, the open int3472 question becomes whether
this is a firmware defect to push back on or something we work around
in-tree (and if in-tree, a per-board quirk vs. generic cross-instance
keying). Worth noting the EPROBE_DEFER idea from last time does not
apply: the map is keyed to the wrong device, not merely registered late.
Let's nail the topology first.

Thanks,
Marco
-----BEGIN PGP SIGNATURE-----

iQJFBAEBCAAvFiEEfCO4BD5l0pgKIbbiWJ8D8BulUDgFAmotjMwRHG1uZW5jaWFA
a2NvcmUuaXQACgkQWJ8D8BulUDhOWhAAm0dWTRnXeg419gpHSz3/fWxNgS/rHgy9
oJmYV4/6kftjSbR3i5zORj1eUAOKhdh4lYmjYN0+7OPu45MAlFHTEB943OCSBx5M
HZQGvIWlKfYiLewUnzYBpuMCk1tHJpjmSvkiU5KIrto47yM1uGW8hff+dmo+QIKI
ir6LaIIAsEhjLfjlK4mQa7EoImMmLfT9tmMpZeJjnsulXAsRgz8GGaLSca+J8/wR
pESrwvcDpQocFdVlBCIBSP6vnrJmGEOzivtb7uDWp3X8yXlPzwtCEE+WEyXghtXN
TSAtIAbezj1LaBSQ24uh6deOZkhVsqZ4t8ms1BWl8/E+XTw4GERMcTxLJJaRxO2T
Btzl95AEnGmxieWcZirrHlWIPTYRdJ8zlMhvKEuzjxbt/kFq8hm1mtvbcSdxOA7L
0Q2cvaTtlFlWRG8QCJTMNhFXKbaioaVLc/wkGiQ4vhrAT1mLX1voiTvaXnfRlk/s
eun0k5XN2+90DVqni0vx3vcZlF5/nnb5OmMJefv7qK89LwrA70ugbbNn2UL9Gxnf
IZqlPs50oyeBe7g7K5gglYgZfu2awMTx9eFcftiv8itH0yUVKXPawVgCXe1gSfrp
Eh4Q7oZEk1UYNk3bCz2RmspfbfwWy1z7Kn5/mWpSWUy/8PCFl1otui/C4snRNgIs
42ajMSg0om4=
=0BwD
-----END PGP SIGNATURE-----