From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751178AbcEIENf (ORCPT ); Mon, 9 May 2016 00:13:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39565 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864AbcEIENb (ORCPT ); Mon, 9 May 2016 00:13:31 -0400 Subject: Re: [RFC PATCH v2 07/10] efi: load SSTDs from EFI variables To: Octavian Purdila , "Rafael J. Wysocki" , Len Brown , Matt Fleming , Mark Brown , Wolfram Sang References: <1461105548-20618-1-git-send-email-octavian.purdila@intel.com> <1461105548-20618-8-git-send-email-octavian.purdila@intel.com> Cc: Joel Becker , linux-acpi@vger.kernel.org, linux-efi@vger.kernel.org, linux-i2c@vger.kernel.org, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, irina.tirdea@intel.com From: Jon Masters Message-ID: Date: Mon, 9 May 2016 00:13:22 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1461105548-20618-8-git-send-email-octavian.purdila@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 09 May 2016 04:13:31 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Octavian, Apologies for missing this earlier, just catching up on this thread... On 04/19/2016 06:39 PM, Octavian Purdila wrote: > This patch allows SSDTs to be loaded from EFI variables. It works by > specifying the EFI variable name containing the SSDT to be loaded. All > variables with the same name (regardless of the vendor GUID) will be > loaded. This sounds very useful during development. However, and using EFI variables isn't so terrible, but I am concerned that this should be standardized through ASWG and at least involve certain other OS vendors so that the variable (GUID) can be captured somewhere. If not in the spec itself, then it should be captured as an external ACPI resource on the UEFI website with a clear pointer to the exact IDs to be used. Can you confirm that's the intention? i.e. that you're allowing a command line option for specifying the ID now because you intend to go ensure that there is a standard one that everyone will use later? I should check (but maybe you know) if the kernel is automatically tainted by this codepath as well? Thanks, Jon. -- Computer Architect | Sent from my Fedora powered laptop