On Tuesday, August 07, 2012, Ming Lei wrote: > On Tue, Aug 7, 2012 at 11:42 PM, Alan Stern <st...@rowland.harvard.edu> wrote: > > > > No, that's really not what the patch is doing. > > > > The idea behind the new API is that "func" will be called as soon as we > > know the device is at full power. That could be after the next runtime > > resume or it could be right away. This is a one-time call; it should > > IMO, in the both two cases, the 'func' should be very similar with > .runtime_post_resume from view of the caller because the caller > don't know what the power state of the device is now, so they may > always think the 'func' should do something similar done in > .runtime_post_resume. > > Also .runtime_post_resume always knows the device's power state > is active, which is same with 'func'. In fact, it doesn't matter if the active > state is the 1st time or other times, does it?
What Alan wanted to say, I think, was that .runtime_post_resume() would have to be always identical, where func() need not be always the same function. Moreover, .runtime_post_resume() would _always_ be run after a device resume, while func() is run only _once_. > > not be made _every_ time the device resumes. > > Suppose the device is always resumed in the path(such as irq context), > the callback is still called every time. Yes, but what if you have _two_ code paths and you want to call different code as func() in each of them? > If the .runtime_post_resume is to be a one-time call, that is easy to do it. No, it isn't. > Also I am wondering why the callback shouldn't be called after resume > in sync context, and it may simplify implementation if the two contexts > (sync vs. async) are kept consistent. I have no idea what you're talking about. We actually have a callback that is run every time a device is resumed. It is called .runtime_idle(). Does it help, though? No, it doesn't. > >> Also, the 'func' should be per driver, not per device since only one > >> 'func' is enough for all same kind of devices driven by one same > >> driver. > > > > But what if the subsystem defines its own dev_pm_info structure? Then > > the driver's dev_pm_info will be ignored by the runtime PM core. All > > the subsystems would have to be changed. > > Suppose .runtime_post_resume is introduced, It is not going to be introduced, period. Thanks, Rafael -- 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
