On Friday 12 June 2009, Alan Stern wrote: > On Fri, 12 Jun 2009, Rafael J. Wysocki wrote: > > > On Friday 12 June 2009, Alan Stern wrote: > > > On Fri, 12 Jun 2009, Rafael J. Wysocki wrote: > > > > > > > So, are you suggesting that the core should only check the "all children > > > > suspended" condition if special flag is set in dev_pm_info? > > > > > > Or rather, check it only if the special flag _isn't_ set. > > > > Where the default is unset, I guess? > > Yep. > > > But then, what about the resuming of the parents before the device is resumed? > > Should the parents be resumed regardless of the flag state? > > Yes. In general you should assume a device's parent (and the device > itself!) needs to be resumed whenever the kernel wants to do something > with the device. The special flag arises because sometimes it's safe > to suspend the parent without suspending the device _if_ the kernel > isn't using the device. > > Imagine an idle disk at the end of a link. We might want to > autosuspend the link without spinning down the disk. When we have to > communicate with the disk again, we autoresume the link. (Including > the case where the communication is a "spin-down" command.) > > > And if so, what's > > the condition for breaking the recurrence? Surely it's not sufficient to check > > if the parent is active, because its parent need not be active if it has this > > special flag set. > > That's a good question. Let's assume that situations like this will be > handled by the drivers. > > For example, suppose A is the parent of B is the parent of C, and A is > suspended but B isn't and C is. What happens when somebody wants to > use C? > > An autoresume request is generated for C. Since C's parent is already > resumed, the runtime_resume method in C's driver is called. The driver > has to do some I/O in order to resume C, so it passes an I/O request up > to B's driver. The request then gets passed up to A's driver. This > driver knows that A is suspended, so it starts an autoresume of A and > waits for the autoresume to complete before carrying out the request. > > Then the I/O can go through, so C gets resumed and everything works > out. > > I don't know how often this sort of pattern will arise. It certainly > could be used in usb-storage; there would be no difficulty starting an > autoresume when an I/O request arrives from the SCSI layer below. In > fact, that is exactly how some early runtime-PM patches for usb-storage > worked. So, the conclusion seems to be that we should break the recurrence at the point we find an already active device or a device with no parent and let the driver(s) handle the more complicated cases. Is this correct? BTW, is __device_release_driver() the right place for blocking the run-time PM temporarily during remove? Best, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
