From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E618780472 for ; Tue, 21 Mar 2017 01:43:16 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 190so5246722itm.0 for ; Tue, 21 Mar 2017 01:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=olKKLIertd7KCZNxWkMA/61ce2yhqV85e5Q+4gJDYVg=; b=H4dPG2EBwZ5Ree0rE5UvG11sxNMvLhk3G8iFoTnbeCtyKgf8vOSZVbCshu0deMUmyD HwBjyCkjNjdBk1enfEPQKYS8CbWvCeIOmEYEUKompZrCdzjSo/NkIyl0Y2P7Oh2Zi97t KQfSM2i4PMIr4R2RFrq33bMy1jvwKhlhxErGY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=olKKLIertd7KCZNxWkMA/61ce2yhqV85e5Q+4gJDYVg=; b=Ji5/ESyYd13h+veo5VGU0cxL5YmN7S18GD3wNiHruJEmu2GJD7ZFtz5dKU/gdD3zJ1 bgwyzShXYFZRQRP+cR02gaVcD1o7wGjCQz1ofkjdhWD9017+0IAF7sdOTVmarCME9nA9 P11hQOMRf85zZXst/TLD8V84Mu0BUAFVqZcixv6gX0hIQ/U9kEpp0OwU6mu0f09tP7rp wmcSz0yxmmD4cFR1er9Uq7+XCoDC/njxdscSIWLGy1oAhxbRvpqgGAcverHNuPVsBBF+ 0agATttg8XPM6HcgWAL9p9aIr+y6X9PyfWy5We+B4Pq7CdjNACjcXZUiwoVgZTQ9WRHq nnCg== X-Gm-Message-State: AFeK/H25Ab6zuyaTa9I3f5vQ3Y/7Rx09Wp/tLdixtxAqqtaI2t1Z3v/xvSd1Xhus2PCM0oj4u5BxRwo4klE1wb0P X-Received: by 10.36.77.10 with SMTP id l10mr1490273itb.59.1490085796291; Tue, 21 Mar 2017 01:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Tue, 21 Mar 2017 01:43:15 -0700 (PDT) In-Reply-To: References: <20170317204731.31488-1-lersek@redhat.com> <20170317204731.31488-6-lersek@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B835B4B@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B8360CA@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B836569@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Tue, 21 Mar 2017 08:43:15 +0000 Message-ID: To: "Zeng, Star" Cc: Laszlo Ersek , edk2-devel-01 , "Kinney, Michael D" , "Yao, Jiewen" , Leif Lindholm Subject: Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:43:17 -0000 Content-Type: text/plain; charset=UTF-8 On 21 March 2017 at 07:10, Ard Biesheuvel wrote: > On 21 March 2017 at 02:27, Zeng, Star wrote: >> Just an idea. >> > > I like it! > >> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions. >> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint. >> > > So could we then upgrade the definition so it is possible to use a > dynamic PCD for this? > Oh, and how is the ordering ensured in this case? We need to set the dynamic PCD at runtime, but obviously before AcpiTableDxe gets a chance to load. If the only way to achieve this is another NULL class library, then this is not much of an improvement. Or could we detect the table-loader node from PEI as well?