On 10/11/23 18:58, Sven van Ashbrook wrote:
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
PCI subsystem does it in pci_pm_init()
- 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?
Most drivers expect the device to be active at probe(). How it gets that way is up to the bus. Note, the driver may call pm_runtime_set_active() but that doesn't call runtime_resume().
Does the driver have a runtime_pm misconfiguration issue here?
No
Perhaps Rafael could clarify?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Docume...