ACPICA did not change the SCI_EN value. The #define associated with the control register has always been 0x0201 in ACPICA. A linux patch changes the value from 0x0201 to 0x0200, and represents a divergence of linux from ACPICA. What ACPICA did was to rename the #define, that is what broke the linux patch. - #define ACPI_PM1_CONTROL_PRESERVED_BITS 0x0201 /* Bit 9, Bit 0 (SCI_EN) */ + #define ACPI_PM1_CONTROL_IGNORED_BITS 0x0201 /* Bits 9, 0(SCI_EN) */ + #define ACPI_PM1_CONTROL_RESERVED_BITS 0xC1F8 /* Bits 14-15, 3-8 */ +#define ACPI_PM1_CONTROL_PRESERVED_BITS \ + (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS) >-----Original Message----- >From: Len Brown [mailto:lenb@xxxxxxxxxx] >Sent: Friday, May 15, 2009 10:50 PM >To: Moore, Robert >Cc: Bob Copeland; Rafael J. Wysocki; Lin, Ming M; Bjorn Helgaas; Zhao, >Yakui; linux-kernel@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx >Subject: RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround > > >> >The BIOS bug workaround mistakenly got disabled >> >when we followed the ACPI specification more closely >> >by ignoring OS updates to that bit. >> >> Not exactly. ACPICA has always preserved the SCI_EN bit. Linux apparently >has a "linux-only" patch to ACPICA that disables this. >> >> The recent version of ACPICA change the #define enough such that the >patch no longer works. > >"We" here means Linux, and thus the description is accurate. > >The fact is that in 2.6.29 Linux had >ACPI_PM1_CONTROL_PRESERVED_BITS 0x0200 >and when "we" updated it to 0x201 via the ACPICA update, >the workaround in the Linux resume code became a NOP. > >-Len -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
