On Wed, 14 Nov 2012, Huang Ying wrote: > > What changes specifically do you mean to be precise? > > I mean the following changes from Alan's email. > > pm_runtime_set_suspended should fail if dev->power.runtime_auto > is clear. > > pm_runtime_forbid should call pm_runtime_set_active if > dev->power.disable_depth > 0. (This would run into a problem > if the parent is suspended and disabled. Maybe > pm_runtime_forbid should fail when this happens.) > > For the second one, is it possible that the device is really in low > power state when pm_runtime_forbid is called? That situation is hard to > deal with too.
Yes, it is possible. I don't see what we can do about it. By disabling the device, the driver has said that it doesn't want to handle any runtime PM callbacks. Without the driver's help, there isn't any good way to bring the device back to full power. On the other hand, the PM core doesn't know the device's actual power state. All it knows is the value of dev->power.runtime_status. So it doesn't have any way to detect when this problem occurs. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
