From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 03F5081ED5 for ; Tue, 15 Nov 2016 08:56:08 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6210861BB6; Tue, 15 Nov 2016 16:56:12 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-97.phx2.redhat.com [10.3.116.97]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFGu9k7031543; Tue, 15 Nov 2016 11:56:10 -0500 To: Evan Lloyd , "edk2-devel (edk2-devel@lists.01.org)" , "ard.biesheuvel@linaro.org" , Star Zeng , Jordan Justen , Feng Tian References: Cc: Lorenzo Pieralisi , Leif Lindholm From: Laszlo Ersek Message-ID: <5863f527-d6b9-55e2-9560-9d138ac9ce1a@redhat.com> Date: Tue, 15 Nov 2016 17:56:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 15 Nov 2016 16:56:12 +0000 (UTC) Subject: Re: Support for ACPI 1.0 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 16:56:08 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 "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.
# BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.
# BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.
# BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.
# BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.
# @Prompt Exposed ACPI table versions. gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|UINT32|0x0001004c See commit e0692789058ee for example. Thanks! Laszlo > > Regards, > Evan > > 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. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >