On Tue, 19 Jul 2022 14:56:51 +0300 Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> wrote: > 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? > Best effort + in general if we do something probe(), we want to do the reverse in remove(). Sure it's not super important, but it's a nice to have. This tends to get 'fixed' by people revisiting the driver after it has merged. > > 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. Generally set it wherever you 'enable' the device as you are indicating the state after that has happened. That might be really early though. > > > 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. > For the cost of about 4-8 lines of code, I think it's worth having, but can also see why you decided against. Jonathan
