On Tue, 17 Oct 2017, Ulf Hansson wrote: > > These functions are wrong, however, because they attempt to reuse the > > whole callback *path* instead of just reusing driver callbacks. The > > *only* reason why it all "works" is because there are no middle layer > > callbacks involved in that now. > > > > If you changed them to reuse driver callbacks only today, nothing would break > > AFAICS. > > Yes, it would. > > First, for example, the amba bus is responsible for the amba bus > clock, but relies on drivers to gate/ungate it during system sleep. In > case the amba drivers don't use the pm_runtime_force_suspend|resume(), > it will explicitly have to start manage the clock during system sleep > themselves. Leading to open coding. I think what Rafael has in mind is that the PM core will call the amba bus's ->suspend callback, and that routine will then be able to call the amba driver's runtime_suspend routine directly, if it wants to -- as opposed to going through pm_runtime_force_suspend. However, it's not clear whether this fully answers your concerns. > Second, it will introduce a regression in behavior for all users of > pm_runtime_force_suspend|resume(), especially during system resume as > the driver may then end up resuming the device even in case it isn't > needed. I believe I have explained why, also several times by now - > and that's also how far you could take the i2c designware driver at > this point. > > That said, I assume the second part may be addressed in this series, > if these drivers convert to use the "driver PM flags", right? Presumably. The problem is how to handle things which need to be treated differently for runtime PM vs. system suspend vs. hibernation. If everything filters through a runtime_suspend routine, that doesn't leave any scope for handling the different kinds of PM transitions differently. Instead, we can make the middle layer (i.e., the bus-type callbacks) take care of the varying tasks, and they can directly invoke a driver's runtime-PM callbacks to handle all the common activities. If that's how the middle layer wants to do it. > However, what about the first case? Is some open coding needed or your > think the amba driver can instruct the amba bus via the "driver PM > flags"? PM flags won't directly be able to cover things like disabling clocks. But they could be useful for indicating explicitly whether the code to take care of those things needs to reside at the driver layer or at the bus layer. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
