Re: [Xen-devel] [PATCH]ACPI: workaround for S3 fail in two facs

>>> "Wei, Gang" <gang.wei@xxxxxxxxx> 25.02.10 06:49 >>>
>ACPI: workaround for S3 fail in two facs tables case
>
>Some legacy BIOS which support ACPI2.0+ may expose two FACS tables via both 
>FADT->FIRMWARE_CTRL and FADT->X_FIRMWARE_CTRL, but only lookup S3 
>waking_vector in the first one. So enhance the X_FIRMWARE_CTRL selection 
>condition by adding FADT->FIRMWARE_CTRL == 0.
>
>Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx>
>
>diff -r e11c8dcbf690 xen/arch/x86/acpi/boot.c
>--- a/xen/arch/x86/acpi/boot.c Wed Feb 24 11:00:11 2010 +0800
>+++ b/xen/arch/x86/acpi/boot.c Thu Feb 25 20:47:37 2010 +0800
>@@ -365,7 +365,7 @@ acpi_fadt_parse_sleep_info(struct acpi_t
>              acpi_sinfo.pm1b_evt_blk.address);
> 
>       /* Now FACS... */
>-      if (fadt->header.revision >= FADT2_REVISION_ID)
>+      if (fadt->header.revision >= FADT2_REVISION_ID && fadt->facs == 0)
>               facs_pa = fadt->Xfacs;
>       else
>               facs_pa = (uint64_t)fadt->facs;

Wouldn't that generally suppress using fadt->Xfacs, since I think in
order to be pre-2.0-OS compatible a BIOS would not normally set
facs to zero when Xfacs is non-zero? Or is that a requirement by the
spec?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread]

Current Thread

[Next in Thread>

Previous by Date:

[Xen-devel] Re: [PATCH] Fix wild ptr deref during device destruction., Jan Beulich

Next by Date:

[Xen-devel] Nouveau on dom0, Arvind R

Previous by Thread:

[Xen-devel] [PATCH]ACPI: workaround for S3 fail in two facs tables case, Wei, Gang

Next by Thread:

Re: [Xen-devel] [PATCH]ACPI: workaround for S3 fail in two facs tables case, Keir Fraser

Indexes:

[Date] [Thread] [Top] [All Lists]