On 7/18/22 20:25, Jonathan Cameron wrote: > What turns this off again? I'd expect to see a devm_add_action_or_reset() > to do that in the !CONFIG_PM case. > > This is also an unusual pattern. As far as I can tell it works. > Normal trick for ensuring !CONFIG_PM works is to: > > 1) Unconditionally turn device on. > 2) Register unconditional device off devm_callback. Very rarely harmful even if device already off > due to runtime pm. If CONFIG_PM is disabled, do we really need to care about the power management on removal? > 3) Then call pm_runtime_set_active() so the state tracking matches. We can add pm_runtime_set_active() before h/w is touched for more consistency. On Steam Deck supplies are always enabled, but this may be not true for other devices. > 4) Call > pm_runtime_mark_last_busy(dev); > pm_runtime_put_autosuspend(dev); > (here you have a function to do this anyway) > to let runtime_pm use same path as normal to autosuspend > > the upshot of this is that if !CONFIG_PM 3 and 4 do nothing and device > is left turned on. Is there something I'm missing that makes that cycle > inappropriate here? The main reason to do this is it then looks exactly > like any other runtime_pm calls elsewhere in the driver, so easier to review. It's appropriate, although caring about PM when it's disabled in kernel config could be unnecessary, IMO. It was my suggestion to keep the h/w enabled on driver's removal with !CONFIG_PM, minimizing the code. -- Best regards, Dmitry
