tools/firmware: remove "_PS0/3" Method

Do not expose the ACPI power management "_PS0/3" Method to guest
firmware.  According to section 3.4 of the APCI specification 4.0, PCI
device control the device power through its own specification but not
through APCI.

Qemu pushes "_PS0/3" to guest will cause a mess between ACPI PM and
PCI PM as a result of incorrect ACPI table shipped with the guest
BIOS, it may cause a failure of PCI device PM state transition(from
PCI_UNKNOWN to PCI_D0).

Signed-off-by: Xudong Hao <xudong.hao@intel.com>
Signed-off-by: Haitao Shan <haitao.shan@intel.com>
Committed-by: Keir Fraser <keir@xen.org>

1 files changed, 0 insertions, 10 deletions

diff --git a/tools/firmware/hvmloader/acpi/mk_dsdt.c b/tools/firmware/hvmloader/acpi/mk_dsdt.c
index dcac5872cd..38bbb04b9a 100644
--- a/tools/firmware/hvmloader/acpi/mk_dsdt.c
+++ b/tools/firmware/hvmloader/acpi/mk_dsdt.c
@@ -323,8 +323,6 @@ int main(int argc, char **argv)
      * the ACPI event:
      *  _EJ0: eject a device
      *  _STA: return a device's status, e.g. enabled or removed
-     * Other methods are optional: 
-     *  _PS0/3: put them here for debug purpose
      * 
      * Eject button would generate a general-purpose event, then the
      * control method for this event uses Notify() to inform OSPM which
@@ -344,14 +342,6 @@ int main(int argc, char **argv)
             stmt("Name", "_ADR, 0x%08x", ((slot & ~7) << 13) | (slot & 7));
             /* _SUN == dev */
             stmt("Name", "_SUN, 0x%08x", slot >> 3);
-            push_block("Method", "_PS0, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x80, \\_GPE.DPT2");
-            pop_block();
-            push_block("Method", "_PS3, 0");
-            stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
-            stmt("Store", "0x83, \\_GPE.DPT2");
-            pop_block();
             push_block("Method", "_EJ0, 1");
             stmt("Store", "0x%02x, \\_GPE.DPT1", slot);
             stmt("Store", "0x88, \\_GPE.DPT2");