There's something happening in this driver that doesn't make much sense to me. According to the pm runtime docs [1] the initial runtime pm status of all devices is 'suspended'. Which I presume, means: if the driver doesn't use any of the pm_runtime_*() functions to tell the core "actually, I am active after probe", then the device remains suspended until explicitly going active, at which point the runtime_resume() callback is invoked. That's the theory. In practice, what do I see on a device containing this bridge? Intel SoC <-> PCIe bus <-> gl9763e bridge <-> eMMC bus <-> eMMC drive at probe() (does not exist in this driver so I stubbed it): [ 0.601542] runtime pm is enabled = 1 (disable_depth == 0) [ 0.601552] runtime pm is active = 2 (usage_count) at probe_slot(): [ 0.602024] runtime pm is enabled = 1 [ 0.602027] runtime pm is active = 2 At add_host(): [ 0.602804] runtime pm is enabled = 1 [ 0.602809] runtime pm is active = 3 It looks like: - nowhere does the gl9763e driver inform runtime pm it's active - the device is active in probe(), probe_slot() and add_host() - the runtime_resume() callback did not get called before probe(), probe_slot(), or add_host(). Why is the runtime_resume() callback not invoked? Does the driver have a runtime_pm misconfiguration issue here? Perhaps Rafael could clarify? [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/power/runtime_pm.rst?h=v6.6.1#n563
