On Wednesday, June 20, 2018 2:23:46 PM CEST Johan Hovold wrote: > On Wed, Jun 20, 2018 at 02:16:59AM -0700, Tony Lindgren wrote: > > Hi, > > > > Adding Rafael and linux-pm to Cc as well. > > > > * Felipe Balbi <ba...@kernel.org> [180619 01:23]: > > > This is a direct consequence of not paying attention to the order of > > > things. If driver were to assume that pm_domain->activate() would do the > > > right thing for the device -- meaning that probe would run with an > > > active device --, then we wouldn't need that pm_runtime_get() call on > > > probe at all. Rather we would follow the sequence: > > > > > > pm_runtime_forbid() > > > pm_runtime_set_active() > > > pm_runtime_enable() > > > > > > /* do your probe routine */ > > > > > > pm_runtime_put_noidle() > > > > > > Then you remove you would need to call pm_runtime_get_noresume() to > > > balance out the pm_runtime_put_noidle() there. > > > > (If you need to know why the pm_runtime_put_noidle(), remember that > > > pm_runtime_set_active() increments the usage counter, so > > > pm_runtime_put_noidle is basically allowing pm_runtime to happen as soon > > > as userspace writes "auto" to /sys/..../power/control) > > That's not correct; pm_runtime_set_active() only increments the usage > counter of a parent (under some circumstances), so unless you have bus > code incrementing the usage counter before probe, the above > pm_runtime_put_noidle() would actually introduce an imbalance.
No, it wouldn't. It balances the incrementation in pm_runtime_forbid(). > And note that that's also the case even if you meant to say that > *pm_runtime_forbid()* increments the usage counter (which it does). Why is it? Surely, after pm_runtime_forbid(dev); pm_runtime_put_noidle(dev); the runtime PM usage counter of dev will be the same as before, won't it? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
