On Tuesday 09 June 2009, Oliver Neukum wrote: > Am Montag, 8. Juni 2009 23:31:58 schrieb Rafael J. Wysocki: > > If ->autosuspend() fails, the device power state may be known, but the core > > can't be sure if the device is active. This information is available to > > the driver and/or the bus type, which should change the status to whatever > > is appropriate. > > That is quite confusing. You'd better define error returns. That might work too, but the information need not be available to the driver immediately. It may need to schedule a reset of the device to recover from the error condition, for example. > One that would mean that the suspension has failed but the device is > unaffected, and another one that means that the device is in an > undefined state now. > > > > The scheme doesn't include any mechanism for communicating runtime > > > power information up the device tree. When a device is autosuspended, > > > its parent's driver should be told so that the driver can consider > > > autosuspending the parent. > > > > I thought the bus type's ->autosuspend() callback could take care of this. > > That can't work because you have to operate between busses. OK, point taken. > > > Likewise, if we want to autoresume a device below an autosuspended > > > parent, the parent should be autoresumed first. Did you want to make the > > > bus subsystem responsible for all of this? > > > > Yes, that was the idea. > > That is an important point. Can some subsytems operate with a parent still > suspended? OK, I see the value of doing that at the core level. I tried to address this in the new version of the patch, which has been sent in my last reply to Alan. Thanks, 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
