> @@ -659,26 +674,61 @@ static pm_message_t resume_event(pm_mess > } > > /** > - * device_suspend_noirq - Shut down one device (late suspend). > - * @dev: Device. > - * @state: PM transition of the system being carried out. > + * __device_suspend_noirq - Execute a "late" suspend callback for given device. > + * @dev: Device to suspend. > + * @state: PM transition of the system being carried out. > * > - * This is called with interrupts off and only a single CPU running. that still looks like useful comment... why delete it? > + * The driver of the device won't receive interrupts while this function is > + * being executed. > */ > @@ -696,13 +746,19 @@ int dpm_suspend_noirq(pm_message_t state > suspend_device_irqs(); > mutex_lock(&dpm_list_mtx); > list_for_each_entry_reverse(dev, &dpm_list, power.entry) { > + dev->power.status = DPM_OFF_IRQ; > error = device_suspend_noirq(dev, state); > if (error) { > pm_dev_err(dev, state, " late", error); > + dev->power.status = DPM_OFF; > + break; > + } > + if (async_error) { > + error = async_error; > break; async_error is 'interesting'. How does locking work in noirq case? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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