On Friday, July 01, 2011, Kevin Hilman wrote: > Kevin Hilman <khilman@xxxxxx> writes: > > > Continuing on the theme of runtime PM interactions with other parts of > > the driver core... > > > > In drivers/base/dd.c:driver_probe_device(), the driver core increments > > the usage count around ->probe(): > > > > [...] > > pm_runtime_get_noresume(dev); > > pm_runtime_barrier(dev); > > ret = really_probe(dev, drv); > > pm_runtime_put_sync(dev); > > > > I'm not following the reason for this. On driver's I'm familar with, > > it's not until ->probe where pm_runtime_enable() is called. What is > > being protected against here? > > > > These seem to exist since the introduction of the runtime PM core, but I > > can't find any explanation. > > > > The documentation refers to the increment by the core, but not the > > reasons why: > > > > If the device bus type's or driver's ->probe() or ->remove() > > callback runs pm_runtime_suspend() or pm_runtime_idle() or their > > asynchronous counterparts, they will fail returning -EAGAIN, because > > the device's usage counter is incremented by the core before > > executing ->probe() and ->remove(). Still, it may be desirable to > > suspend the device as soon as ->probe() or ->remove() has finished, > > so the PM core uses pm_runtime_idle_sync() to invoke the > > subsystem-level idle callback for the device at that time. > > > > On a side note, the bit about -EAGAIN above is not accurate with today's > > code. For example, __pm_runtime_suspend() returns zero when the usage > > count decrement is non-zero, so callers can't currently know that doing > > a pm_runtime_suspend() or pm_runtime_put_sync() in their ->probe() > > actually didn't happen. > > Oops, I'm not quite right here. > > The doc is actually right here if the driver uses pm_runtime_suspend() > or pm_runtime_idle() in ->probe(). It's only when drivers use > pm_runtime_put_sync() where there wouldn't be an -EAGAIN, but that seems > correct. Sorry for the noise. > > I'm still confused about the usage_count increment around ->probe > though. In theory it is possible that a subsystem (e.g. bus type) will enable runtime PM for devices without drivers and will (for example) put them into low power states until the drivers are loaded. Then, it makes sense for the core to prevent such transitions from racing with .probe(). I'm not sure if this happens in practice, though, but also I'm not sure whether or not that's used by USB. Moreover, even if that doesn't happen right now, it may start to happen at one point. Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
