From: Evan Lloyd <Evan.Lloyd@arm.com>
To: Laszlo Ersek <lersek@redhat.com>,
"edk2-devel (edk2-devel@lists.01.org)" <edk2-devel@ml01.01.org>,
"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
Star Zeng <star.zeng@intel.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Feng Tian <feng.tian@intel.com>
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Leif Lindholm <leif.lindholm@linaro.org>
Subject: Re: Support for ACPI 1.0
Date: Tue, 15 Nov 2016 19:27:02 +0000 [thread overview]
Message-ID: <AM5PR0801MB176269FDBBCA43EEC10B03718BBF0@AM5PR0801MB1762.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <5863f527-d6b9-55e2-9560-9d138ac9ce1a@redhat.com>
Hi Laszlo.
Thank you for the response. Comments inline below.
>-----Original Message-----
>From: Laszlo Ersek [mailto:lersek@redhat.com]
>Sent: 15 November 2016 16:56
>To: Evan Lloyd; edk2-devel (edk2-devel@lists.01.org);
>ard.biesheuvel@linaro.org; Star Zeng; Jordan Justen; Feng Tian
>Cc: Lorenzo Pieralisi; Leif Lindholm
>Subject: Re: [edk2] Support for ACPI 1.0
>
>On 11/15/16 14:08, Evan Lloyd wrote:
>> There is some wonderfully convoluted code in
>MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
>> A major cause of the complexity arises from the special cases related to
>support for "EFI_ACPI_TABLE_VERSION_1_0B" or not
>("ACPI_TABLE_VERSION_GTE_2_0").
>>
>> We are seeing problems (SCT fails) related to this with the current code,
>and have been looking at a fix.
>>
>> However, it seems reasonable to question the requirement to support
>ACPI 1.0 nowadays.
>> Is there any need to retain support for such obsolete table versions?
>> Should there be, could it at least be split out into a distinct build option?
>
>It seems that this can be controlled through PcdAcpiExposedTableVersions -
>- is that insufficient for your purpose? From
The USE of the code can indeed be controlled with the Pcd.
However my point is that to accommodate the idiosyncrasies of "ACPI_1_0B", the code is complex and obscure.
It also has bugs, largely because of that complexity.
Were ACPI 1.0 support removed, it would become far simpler, more maintainable, and easier to debug.
All the optional code for VERSION_1_0B or GTE_2_0 would become redundant, and the updates we need to make would be simplified.
For ARM, we only really care about ACPI 5.0 or later.
I do not know what the support requirements might be for other platforms, but ACPI 2.0 came out in 2000, so it seems reasonable to encourage people into this century, if not this decade.
>"MdeModulePkg/MdeModulePkg.dec":
>
> ## Indicates which ACPI versions are targeted by the ACPI tables exposed
>to the OS
> # These values are aligned with the definitions in
>MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
> # BIT 1 - EFI_ACPI_TABLE_VERSION_1_0B.<BR>
> # BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.<BR>
> # BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.<BR>
> # BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.<BR>
> # BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.<BR>
> # @Prompt Exposed ACPI table versions.
>
Wot, no ACPI 6? (That is one issue we have found, especially with the GTE_2_0 macro.)
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|
>UINT32|0x0001004c
>
>See commit e0692789058ee for example.
>
>Thanks!
>Laszlo
>
>>
>> Regards,
>> Evan
...
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
prev parent reply other threads:[~2016-11-15 19:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-15 13:08 Support for ACPI 1.0 Evan Lloyd
2016-11-15 16:56 ` Laszlo Ersek
2016-11-15 19:27 ` Evan Lloyd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AM5PR0801MB176269FDBBCA43EEC10B03718BBF0@AM5PR0801MB1762.eurprd08.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox