Hi, On Wed, Feb 23, 2022 at 7:55 AM Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > How about a middle ground, though: we could add a devm function that > > does all the magic. Somewhat recently devm_pm_runtime_enable() was > > added. What if we add a variant for those that use autosuspend, like: > > > > devm_pm_runtime_enable_with_autosuspend(dev, initial_delay) > > > > That would: > > * pm_runtime_enable() > > * pm_runtime_set_autosuspend_delay() > > * pm_runtime_use_autosuspend() > > * Use devm_add_action_or_reset() to undo everything. > > > > Assuming that the pm_runtime folks are OK with that, we could > > transition things over to the new function once it rolls into > > mainline. > > > > So this doesn't magically fix all existing code but provides a path to > > make this more discoverable. > > Sounds like a good idea. I wonder if this could be handled by > devm_pm_runtime_enable() actually. If a driver calls > devm_pm_runtime_enable() and then enables auto-suspend, can't the > runtime PM core reasonably expect that auto-suspend should be disabled > at .remove() time ? The pm_runtime_disable_action() function could > disable auto-suspend unconditionally (assuming > pm_runtime_use_autosuspend() and pm_runtime_dont_use_autosuspend() don't > need to be balanced, if they do, then I'll just go cry in a corner). I like your idea. I think you're right that we can just leverage the existing function. This yak didn't look to hairy, so I posted a patch: https://lore.kernel.org/r/20220223083441.1.I925ce9fa12992a58caed6b297e0171d214866fe7@changeid I guess now we see what Rafael thinks. ;-) -Doug
