[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACdnJutomLNthYDzEc0wFBcBHK5iqnk0p-hkAkp57zQZ38oGPA@mail.gmail.com>
Date: Mon, 26 Aug 2019 10:40:25 -0700
From: Matthew Garrett <mjg59@...gle.com>
To: Seunghun Han <kkamagui@...il.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
Peter Huewe <peterhuewe@....de>,
"open list:TPM DEVICE DRIVER" <linux-integrity@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for
supporting AMD's fTPM
On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han <kkamagui@...il.com> wrote:
> To support AMD's fTPM, I removed the busy bit from the ACPI NVS area like
> the reserved area so that AMD's fTPM regions could be assigned in it.
drivers/acpi/nvs.c saves and restores the contents of NVS regions, and
if other drivers use these regions without any awareness of this then
things may break. I'm reluctant to say that just unilaterally marking
these regions as available is a good thing, but it's clearly what's
expected by AMD's implementation. One approach would be to have a
callback into the nvs code to indicate that a certain region should be
handed off to a driver, which would ensure that we can handle this on
a case by case basis?
Powered by blists - more mailing lists