use of pm_runtime_disable() from driver probe?

[Kevin Hilman <khilman@ti.com>]

Hello,

I've got a question around the proper use of pm_runtime_disable() in a
driver's ->probe method.  Basically, using pm_runtime_disable() in
->probe() (e.g because of a error/failure) can result in the device
remaning runtime enabled forever.  This is because the driver core wraps
the probe in _get_noresume()/_put_sync() so any usage of _put_sync() in
->probe itself does not trigger an actual device runtime suspend.  If
the driver also calls pm_runtime_disable() in probe, that results in the
device remaining runtime enabled.

Consider this example (based on drivers/mmc/host/omap_hsmmc.c).  In the
normal/success path, everything works fine.  But in the failure case,
the after the failed probe, the driver calls pm_runtime_disable() and
the device is left runtime enabled:

driver_probe()
{
    /* usage count == 1; due to _get_noresume() in driver core */
    pm_runtime_enable();
    pm_runtime_get_sync()
    /* usage_count == 2 */
  
    /* probe HW */
    if (failure)
        goto error;    

    /* otherwise, finish HW init */

    pm_runtime_put_sync();
    /* usage_count == 1 */
    /* _put_sync() in driver core will make count = 0
     * and device will be runtime suspended */
    return 0;  

 error:
    pm_runtime_put_sync();
    /* usage_count = 1 */
    pm_runtime_disable();

    /* Now, the _put_sync() in driver core will not actually suspend
       since runtime PM has been disabled. */
}


So, the question is: is it right to use pm_runtime_disable() this way?

Removing it means the device is left in runtime suspended state even in
the error case.  However, without the pm_runtime_disable(), if this
driver was a module, repeated attempts to load would result in
unbalalced calls to pm_runtime_enable.

What is the right way to handle the runtime PM enable/disable in a
failed probe attempt?

Thanks,

Kevin