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/Docume...