Merge tag 'x86_urgent_for_v6.0-rc8' of git://git.kernel.org/pub/scm/linux/kernel...

[people/ms/linux.git] / drivers / acpi / processor_idle.c

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 16a1663d02d460579e61c9e98ff2d1ca5d0ba0c8..9f40917c49efbf2a7562901edd7be29f933fc6c5 100644 (file)
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -531,10 +531,27 @@ static void wait_for_freeze(void)
        /* No delay is needed if we are in guest */
        if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
                return;
+       /*
+        * Modern (>=Nehalem) Intel systems use ACPI via intel_idle,
+        * not this code.  Assume that any Intel systems using this
+        * are ancient and may need the dummy wait.  This also assumes
+        * that the motivating chipset issue was Intel-only.
+        */
+       if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+               return;
 #endif
-       /* Dummy wait op - must do something useless after P_LVL2 read
-          because chipsets cannot guarantee that STPCLK# signal
-          gets asserted in time to freeze execution properly. */
+       /*
+        * Dummy wait op - must do something useless after P_LVL2 read
+        * because chipsets cannot guarantee that STPCLK# signal gets
+        * asserted in time to freeze execution properly
+        *
+        * This workaround has been in place since the original ACPI
+        * implementation was merged, circa 2002.
+        *
+        * If a profile is pointing to this instruction, please first
+        * consider moving your system to a more modern idle
+        * mechanism.
+        */
        inl(acpi_gbl_FADT.xpm_timer_block.address);
 }