Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp5502781ybl; Tue, 27 Aug 2019 05:48:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqz7rNuTisrqLeWCnYHcQbr69tlREgY24NgbveHVLHjUrGkodBF7q8aFB9+AqW/MPPDiEKMh X-Received: by 2002:a17:90b:289:: with SMTP id az9mr25755649pjb.5.1566910108857; Tue, 27 Aug 2019 05:48:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566910108; cv=none; d=google.com; s=arc-20160816; b=0D7K2k0A9pchG8b8WZzKipESRcFqNaxIJmpQUc8rDAfhz1Vxr1BGrwGC05oWybK0/Q SwFzy88sRgj0NX5WsvJe3R6tGN1S6KAzJqaY5SvdYL/MXh7VJ109ZHLAw/wcPGQBnrqr WYtoEQRQ3I7bT5h53PctLrAdB8ckzk7X0dQ4Sgna1fCPavjLyuYToLpoRYfF23pZOhr8 9d0Edfj2acwOURtKce40yJJsgR9POe/2vi0BPSwjiwAESVrlz9i46sNoZsg1B8pR7fz1 h8A7niVbPqq1dPYuOB015Dha85KgyqYtIBhH/KCJhL7LP0/nKc5QrPHsC4v/ytdRacXQ y2VQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=PTulsosIv+kTpXsIba1YTzINEggdHAWSvNEEzCGkQQs=; b=UPIMud6o3yPBvhe1hjs8fYtoCTs9bQOdpbVd35JtUT739Y+rop+GmS4zZK/VNNWj41 jHpn0+H2/VjXmU2SEJm/PKtm5226zEU0/zZMl565mPGK9h5EBzZ5ukqVWK06PMDk2TTe QYy0WiKv2DKBKel5HArMFEpeYgFmWlrLwqfuQeS1yHZHrZ+ptcSEJglzNmEmbhKqCkBv w0q133yEipz0y775V7mFIQC5A6MT2wKKlRDMhXC5UpvfagxtaJWfSmKZEG0ungsxaTPF eb7hvq6HyZx4qI82//G1IWyB9HBi4TMxCc5jjadi+XnoSbUw7bvUTc6qQbMFWcY4kCFu P0jA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n23si11579156pgv.163.2019.08.27.05.48.12; Tue, 27 Aug 2019 05:48:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729166AbfH0MrL (ORCPT + 99 others); Tue, 27 Aug 2019 08:47:11 -0400 Received: from mga18.intel.com ([134.134.136.126]:36325 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726170AbfH0MrL (ORCPT ); Tue, 27 Aug 2019 08:47:11 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2019 05:47:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,437,1559545200"; d="scan'208";a="187907181" Received: from jsakkine-mobl1.fi.intel.com (HELO localhost) ([10.237.66.169]) by FMSMGA003.fm.intel.com with ESMTP; 27 Aug 2019 05:47:08 -0700 Date: Tue, 27 Aug 2019 15:47:07 +0300 From: Jarkko Sakkinen To: Matthew Garrett Cc: Seunghun Han , Matthew Garrett , Peter Huewe , "open list:TPM DEVICE DRIVER" , Linux Kernel Mailing List Subject: Re: [PATCH] x86: tpm: Remove a busy bit of the NVS area for supporting AMD's fTPM Message-ID: <20190827124707.yhqtaqa4ur6i45h7@linux.intel.com> References: <20190826081752.57258-1-kkamagui@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 26, 2019 at 10:40:25AM -0700, Matthew Garrett wrote: > On Mon, Aug 26, 2019 at 1:18 AM Seunghun Han 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? What if E820 would just have a small piece of code just for fTPM's e.g. it would check the ACPI tree for fTPM's and ignore TPM regions. /Jarkko