On Tue, 10 Jul 2012, Rafael J. Wysocki wrote: > > > Anyway, you can't force the device into a low-power state using > > > runtime PM after a failing probe, at least in general. > > > > Well, using PM domains, that's exactly what can happen if the driver > > doesn't call pm_runtime_disable() because the _put_sync() in the driver > > core will trigger the PM domain callbacks. > > OK, so if you have PM domains, then the case is equivalent to having a bus > type with its own runtime PM callbacks. In that case, if .probe() fails, > it obviously doesn't mean that the device shouldn't be power managed, > so the driver shouldn't call pm_runtime_disable(). > > Generally, if runtime PM was enabled for a device before .probe() has been > called, the driver shouldn't disable it in .probe() whatever the reason, > because it may not have enough information for deciding whether or not > runtime PM should be disabled. So if the PM domain code called pm_runtime_enable() then the domain code should be responsible for calling pm_runtime_disable() too, presumably after putting the device back into a low-power state. I'm not sure when that would occur, however. Immediately after registering the device, if no driver is bound? In the case where the probe routine called pm_runtime_enable(), you're stuck. The probe routine _has_ to call pm_runtime_disable() when a failure occurs, to keep the disable count balanced. Alan Stern
