Re: [PATCH v9 2/2] iio: light: Add support for ltrf216a sensor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux