Something like devm_pm_runtime_enable desirable?

Something like devm_pm_runtime_enable desirable?

[Heiner Kallweit]

I have a runtime pm enabled driver which uses device-managed resources
only and therefore wouldn't need a remove callback. The remove callback
does pm_runtime_disable only.
Therefore I'm wondering whether something like devm_pm_runtime_enable
would be desirable doing the pm_runtime_disable automagically.

I can't really imagine that I'm the first one with this idea so I
guess there is some reason why it doesn't exist yet ..

Re: Something like devm_pm_runtime_enable desirable?

[Rafael J. Wysocki]

On Mon, Nov 27, 2017 at 12:13 AM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> I have a runtime pm enabled driver which uses device-managed resources
> only and therefore wouldn't need a remove callback. The remove callback
> does pm_runtime_disable only.
> Therefore I'm wondering whether something like devm_pm_runtime_enable
> would be desirable doing the pm_runtime_disable automagically.
>
> I can't really imagine that I'm the first one with this idea so I
> guess there is some reason why it doesn't exist yet ..

You also need to ensure that the device is left in the state in which
your driver will expect it to be in on the next probe in case the
driver module is unloaded and loaded again.  I'm not sure if devm_ can
do that generically enough.

Thanks,
Rafael

Re: Something like devm_pm_runtime_enable desirable?

[Heiner Kallweit]

Am 27.11.2017 um 02:21 schrieb Rafael J. Wysocki:
> On Mon, Nov 27, 2017 at 12:13 AM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> I have a runtime pm enabled driver which uses device-managed resources
>> only and therefore wouldn't need a remove callback. The remove callback
>> does pm_runtime_disable only.
>> Therefore I'm wondering whether something like devm_pm_runtime_enable
>> would be desirable doing the pm_runtime_disable automagically.
>>
>> I can't really imagine that I'm the first one with this idea so I
>> guess there is some reason why it doesn't exist yet ..
> 
> You also need to ensure that the device is left in the state in which
> your driver will expect it to be in on the next probe in case the
> driver module is unloaded and loaded again.  I'm not sure if devm_ can
> do that generically enough.
> 
Sure, the device state needs to be managed properly. I just see that lots
of drivers which have the reversed rpm calls in their probe error path and
in remove, what in several cases could be simplified by using the devm
mechanism.
I see this at least for the following function pairs:
pm_runtime_enable -> pm_runtime_disable
pm_runtime_use_autosuspend -> pm_runtime_dont_use_autosuspend

One example would be drivers/i2c/busses/i2c-omap.c, with some IMO
uncritical reordering of rpm calls.

> Thanks,
> Rafael
> 
Rgds, Heiner

Re: Something like devm_pm_runtime_enable desirable?

[Rafael J. Wysocki]

On Tue, Nov 28, 2017 at 10:12 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
> Am 27.11.2017 um 02:21 schrieb Rafael J. Wysocki:
>> On Mon, Nov 27, 2017 at 12:13 AM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>> I have a runtime pm enabled driver which uses device-managed resources
>>> only and therefore wouldn't need a remove callback. The remove callback
>>> does pm_runtime_disable only.
>>> Therefore I'm wondering whether something like devm_pm_runtime_enable
>>> would be desirable doing the pm_runtime_disable automagically.
>>>
>>> I can't really imagine that I'm the first one with this idea so I
>>> guess there is some reason why it doesn't exist yet ..
>>
>> You also need to ensure that the device is left in the state in which
>> your driver will expect it to be in on the next probe in case the
>> driver module is unloaded and loaded again.  I'm not sure if devm_ can
>> do that generically enough.
>>
> Sure, the device state needs to be managed properly. I just see that lots
> of drivers which have the reversed rpm calls in their probe error path and
> in remove, what in several cases could be simplified by using the devm
> mechanism.
> I see this at least for the following function pairs:
> pm_runtime_enable -> pm_runtime_disable
> pm_runtime_use_autosuspend -> pm_runtime_dont_use_autosuspend
>
> One example would be drivers/i2c/busses/i2c-omap.c, with some IMO
> uncritical reordering of rpm calls.

If there are patterns that are sufficiently common to be covered by
devm_ things, I guess it would make sense to do that except that you'd
need one devm_ variant per pattern so to speak.

Thanks,
Rafael