On Sun, 14 Aug 2022 22:12:59 +0300
Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> On Sat, Aug 13, 2022 at 7:02 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> > On Mon, 8 Aug 2022 11:34:23 +0200
> > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > > On Sun, Aug 7, 2022 at 9:11 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
> > > > Here we could use DEFINE_RUNTIME_DEV_PM_OPS() but that would have the
> > > > side effect of providing suspend and resume support. That would be
> > > > harmless but also of little purpose as this driver does very simplistic
> > > > power management with synchronous power up and down around individual
> > > > channel reads.
> > > >
> > > > In general these new PM macros avoid the need to mark functions
> > > > __maybe_unused, whilst still allowing the compiler to remove them
> > > > if they are unused.
> > >
> > > ...
> > >
> > > > static const struct dev_pm_ops rzg2l_adc_pm_ops = {
> > > > - SET_RUNTIME_PM_OPS(rzg2l_adc_pm_runtime_suspend,
> > > > - rzg2l_adc_pm_runtime_resume,
> > > > - NULL)
> > > > + RUNTIME_PM_OPS(rzg2l_adc_pm_runtime_suspend,
> > > > + rzg2l_adc_pm_runtime_resume,
> > > > + NULL)
> > > > };
> > >
> > > DEFINE_RUNTIME_DEV_PM_OPS() ?
> > >
> > Disagreeing with the patch description argument on why I didn't do that?
> > The extra ops set will never have anything to do... Mostly harmless,
> > but kind of gives the wrong impression of what is going on in this
> > driver.
>
> As per thread with Paul, this patch has no function change intentions,
> but also, if tested on hardware, enabling system sleep states
> shouldn't be harmful.
>
This one is different from that case where there might be side effects.
Here the suspend and resume are (I think) guaranteed to have nothing
to do in all cases - because the driver does synchronous power
up and power down in all paths. So in all cases we are already in runtime
suspended state on a call to suspend.
Joanthan
