Some more thoughts... Magnus, you might have some insights here. It occurred to me that some devices can switch power levels very quickly, and the drivers might therefore want the runtime suspend and resume methods to be called as soon as possible, even in interrupt context. In terms of the current framework, this probably means holding the runtime PM lock (i.e., not releasing it) across the calls to ->runtime_suspend and ->runtime_resume. It also means that pm_request_suspend and pm_request_resume should carry out their jobs immediately instead of queuing a work item. (Unless the current status is RPM_SUSPENDING or RPM_RESUMING, which should never happen.) Should there be a flag in dev_pm_info to select this behavior? When a device structure is unregistered and deallocated, we have to insure that there aren't any pending runtime PM workqueue items. Hence device_del should call a routine that changes the status to an exceptional state (not RPM_ERROR but something else) to prevent new requests from being queued, and then calls cancel_work_sync or cancel_delayed_work_sync as required. Similarly, we should insure that runtime PM calls made before the device is registered don't do anything. So when the device structure is first created and the contents are all 0, this should also be interpreted as an exceptional state. We could call it RPM_UNREGISTERED and use it for both purposes. Alan Stern -- 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
