>> Also wanted to ask - do you think acquiring spinlock every time before >> even checking if parent supports runtime PM, optimal? > You need to change your thinking. You're making a very basic mistake, > and you have made the same mistake in every email message on this > subject. > > You keep talking about "parent supports runtime PM". But that's not > what the code actually checks. > > For one thing, this isn't really about the parent device's capabilities > -- runtime support is at least as much a property of the driver as of > the device. But more importantly, the field you're checking doesn't > mean what you think it means. If parent->power.disable_depth > 0, it > doesn't mean that the parent doesn't support runtime PM. It means that > the parent is _currently disabled_ for runtime PM -- and the parent may > become enabled at some time in the future. > > That's why disable_depth is manipulated under spinlock protection. One > thread might be looking at it while another thread is changing it. Not > using the spinlock would leave you open to races. > > The question of efficiency or optimality depends on how often we have a > device using runtime PM whose parent is disabled. I don't know how > often that will occur. As more and more drivers start implementing > runtime PM, it will occur less and less frequently. > > The most troublesome case arises when you have a parent which is > disabled for runtime PM and later on becomes enabled. This may not > happen very often -- it may not happen at all. I would expect that if > a device changes from disabled to enabled, it probably does so before > acquiring any children. But we can't be certain of this. OK, get what you are saying. I was thinking of a particular use case and before I talk about that let me prototype and see if I hit this particular case. Regards, Nithish Mahalingam _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
