On Wed, Jun 20, 2018 at 1:05 PM, Felipe Balbi <ba...@kernel.org> wrote: > "Rafael J. Wysocki" <raf...@kernel.org> writes: > >> On Wed, Jun 20, 2018 at 11:27 AM, Felipe Balbi <ba...@kernel.org> wrote: >>> >>> Hi, >>> >>> Tony Lindgren <t...@atomide.com> writes: >>>> * 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() >> >> Why do you need the _forbid() thing? >> >> Does the default user space control setting need to be changed? > > wouldn't that race with a udev rule writing "auto" power/control as soon > as device is added?
Why would it? >>>>> (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) >>>> >>>> I wonder if we could also remove the need for drivers to call >>>> pm_runtime_putnoidle() at the end of the probe? If we had >>>> pm_runtime_init_enabled() implemented. >>> >>> probably not. We want to block runtime pm during probe, until the device >>> is fully initialized, the only way to do that is to increment rpm usage >>> counter. >> >> That or enable it only at the end. But I guess you want to >> runtime-resume it earlier, don't you? > > well, if arch implements pm_domain->activate() and guarantees that > device is already running, with clocks stable during probe, then > enabling runtime pm at the end is probably the best idea. But if you call pm_runtime_set_active() at any point, you're assuming that the device is active anyway. -- 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
