ACPI PM: restore the 2.6.24 suspend ordering

ACPI PM: restore the 2.6.24 suspend ordering

Some time ago it turned out that our suspend code ordering broke some
NVidia-based systems that hung if _PTS was executed with one of the PCI
devices, specifically a USB controller, in a low power state.  Then, it was
noticed that the suspend code ordering was not compliant with ACPI 1.0,
although it was compliant with ACPI 2.0 (and later), and it was argued that
the code had to be changed for that reason (ref.
http://bugzilla.kernel.org/show_bug.cgi?id=9528).

So we did, but evidently we did wrong, because it's now turning out that some
systems have been broken by this change (refs.
http://bugzilla.kernel.org/show_bug.cgi?id=10340 ,
https://bugzilla.novell.com/show_bug.cgi?id=374217#c16).  [I said at that time
that something like this might happend, but the majority of people involved
thought that it was improbable due to the necessity to preserve the compliance
of hardware with ACPI 1.0.] This actually is a quite serious regression from
2.6.24.

Moreover, the ACPI 1.0 ordering of suspend code introduced another issue that
I have only noticed recently.  Namely, if the suspend of one of devices fails,
the already suspended devices will be resumed without executing _WAK before,
which leads to problems on some systems (for example, in such situations
thermal management is broken on my HP nx6325).  Consequently, it also breaks
suspend debugging on the affected systems.

Note also, that the requirement to execute _PTS before suspending devices does
not really make sense, because the device in question may be put into a low
power state at run time for a reason unrelated to a system-wide suspend.

For the reasons outlined above, the change of the suspend ordering
should be reverted, which is done by this patch.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>