Now, there is a reason why calling pm_runtime_set_suspended() on a
device after disabling runtime PM for it is a good idea at all.
Namely, disabling runtime PM alone does not release the device's
suppliers or its parent, so if you want to release them after
disabling runtime PM for the device, you need to do something more.
I'm thinking that this is a mistake in the design of the runtime PM
core.
Well, this is the order in which the original driver worked before
anyways. As a quick fix, would it work if we created a devm function
that would pm_runtime_set_active(), immediately followed by
pm_runtime_enable(), and on cleanup it would pm_runtime_set_suspended()
followed by pm_runtime_disable_action() (i.e.
pm_runtime_dont_use_autosuspend() and pm_runtime_disable())?
On cleanup you'd need to ensure that pm_runtime_disable() is followed
by pm_runtime_set_suspended() (not the other way around). Also
pm_runtime_dont_use_autosuspend() needs to be called when runtime PM
is still enabled.
With the above taken into account, it would work.