On Sun, 24 Jan 2010, Rafael J. Wysocki wrote:
> The async threads started for different devices as a result of
> calling async_schedule() are synchronized with each other and with
> the main suspend/resume thread with the help of completions, in the
> following way:
> (1) There is a completion, power.completion, for each device object.
> (2) Each device's completion is reset before calling async_schedule()
> for the device or, in the case of devices with the
> power.async_suspend flags unset, before executing the device's
> suspend and resume callbacks.
> (3) During suspend, right before running the bus type, device type
> and device class suspend callbacks for the device, the PM core
> waits for the completions of all the device's children to be
> completed.
> (4) During resume, right before running the bus type, device type and
> device class resume callbacks for the device, the PM core waits
> for the completion of the device's parent to be completed.
> (5) The PM core completes power.completion for each device right
> after the bus type, device type and device class suspend (or
> resume) callbacks executed for the device have returned.
...
> /**
> + * dpm_wait - Wait for a PM operation to complete.
> + * @dev: Device to wait for.
> + * @async: If unset, wait only if the device's power.async_suspend flag is set.
> + */
> +static void dpm_wait(struct device *dev, bool async)
> +{
> + if (!dev)
> + return;
> +
> + if (async || dev->power.async_suspend)
> + wait_for_completion(&dev->power.completion);
> +}
There needs to be a public interface to this function available for
drivers that have non-tree constraints. The arguments should be the
device to wait for and the device doing the waiting (needed only to
determine whether the caller is running synchronously or not).
This will be necessary for USB. In fact, your current code (with patch
7/8 applied) is subject to a race that will sometimes cause a
non-high-speed USB device to fail to resume from hibernation.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
