PM / core: Add SMART_SUSPEND driver flag

from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before*

invoking device drivers' ``->suspend`` callbacks (or equivalent).

Some bus types and PM domains have a policy to resume all devices from runtime

suspend upfront in their ``->suspend`` callbacks, but that may not be really

necessary if the driver of the device can cope with runtime-suspended devices.

The driver can indicate that by setting ``DPM_FLAG_SMART_SUSPEND`` in

:c:member:`power.driver_flags` at the probe time, by passing it to the

:c:func:`dev_pm_set_driver_flags` helper.  That also may cause middle-layer code

(bus types, PM domains etc.) to skip the ``->suspend_late`` and

``->suspend_noirq`` callbacks provided by the driver if the device remains in

runtime suspend at the beginning of the ``suspend_late`` phase of system-wide

suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM

has been disabled for it, under the assumption that its state should not change

after that point until the system-wide transition is over.  If that happens, the

driver's system-wide resume callbacks, if present, may still be invoked during

the subsequent system-wide resume transition and the device's runtime power

management status may be set to "active" before enabling runtime PM for it,

so the driver must be prepared to cope with the invocation of its system-wide

resume callbacks back-to-back with its ``->runtime_suspend`` one (without the

intervening ``->runtime_resume`` and so on) and the final state of the device

must reflect the "active" status for runtime PM in that case.

During system-wide resume from a sleep state it's easiest to put devices into

the full-power state, as explained in :file:`Documentation/power/runtime_pm.txt`.

Refer to that document for more information regarding this particular issue as

	if (dev->power.syscore)

		return 0;

	WARN_ON(dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) &&

		!pm_runtime_enabled(dev));

	/*

	 * If a device's parent goes into runtime suspend at the wrong time,

	 * it won't be possible to resume the device.  To prevent this we

 *

 * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.

 * SMART_PREPARE: Check the return value of the driver's ->prepare callback.

 * SMART_SUSPEND: No need to resume the device from runtime suspend.

 *

 * Setting SMART_PREPARE instructs bus types and PM domains which may want

 * system suspend/resume callbacks to be skipped for the device to return 0 from

 * other words, the system suspend/resume callbacks can only be skipped for the

 * device if its driver doesn't object against that).  This flag has no effect

 * if NEVER_SKIP is set.

 *

 * Setting SMART_SUSPEND instructs bus types and PM domains which may want to

 * runtime resume the device upfront during system suspend that doing so is not

 * necessary from the driver's perspective.  It also may cause them to skip

 * invocations of the ->suspend_late and ->suspend_noirq callbacks provided by

 * the driver if they decide to leave the device in runtime suspend.

 */

#define DPM_FLAG_NEVER_SKIP	BIT(0)

#define DPM_FLAG_SMART_PREPARE	BIT(1)

#define DPM_FLAG_SMART_SUSPEND	BIT(2)

struct dev_pm_info {

	pm_message_t		power_state;