Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2477271ybl; Thu, 29 Aug 2019 08:42:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqxY7jwjYWV2YMkWO+xdk6HEi89F60RD4NnVKJlrQQVQcdTOpd7mAGiN1U1Pac27XoQzbpCd X-Received: by 2002:a63:6888:: with SMTP id d130mr8521199pgc.197.1567093320994; Thu, 29 Aug 2019 08:42:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567093320; cv=none; d=google.com; s=arc-20160816; b=XtKxY962R2joD+3lB72flfPVx3xOx2hCPOYE2lkHHJtojojQhjT0pMurIl4UPr9aKD X5fRz0Js2F9Jca+7nUpM5R0wRbtPDNwRj6QnQSQv7a6i+k4AFc8SUNrVp84cfc7tqfuR XOHrcfkpLLTJkW8sjjIIhVEQO+En+gsm70ofrD10LdAtXaLybKmMtqYAFa+O3LEbqGp5 CzTV/NN9XurJXoYfUsO4M1XzHffh4vNt08ww/B11ly/kvZ+1J6QnnhXKEjkWxBRs3+Sr AAtg5+m+wkMIkLHkU+g89KbasfuLHgQj9+El/q9QkLZNlTTR/giSIbJRbHOlvAMdcNuX beFA== 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=AyA7j8LkLJD9buDwC6FBI0f8Cf2XszKmVRfadI8wHZw=; b=lRMZFO9mYbYQV9+tcdWiXmYjQE17FeayKPRnS8/9V6of1QnjVNmTmZ525dDVcCtKL4 rCo69RMlfLNWVAcYsIaMy9Cs6+cjudnMp/ky0cds1hdvPekWf44vQq54C8Aeyk6PHFvo emvmiwNiBLKpUZdh6khYz6+s4ndYDAoBG09DB1U5s+Em6moM/gRlh5qgiETu3+lludjI oM7440cpRpQeBSo1z8wwjrq6WtOp12tScYq0UBk0zUYvF9zZq+a+RBFRdvfnCl/dJS4a Yv1gjVGA58tdc/c/jA0miM7qFfAOiGkmuSz6ONMzCAYQ6A2QVH5Q2f46EAPR8vOdrEy9 S8ug== 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 v10si2188314plo.384.2019.08.29.08.41.44; Thu, 29 Aug 2019 08:42:00 -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 S1727244AbfH2PjW (ORCPT + 99 others); Thu, 29 Aug 2019 11:39:22 -0400 Received: from mga03.intel.com ([134.134.136.65]:59954 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726852AbfH2PjW (ORCPT ); Thu, 29 Aug 2019 11:39:22 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2019 08:39:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,443,1559545200"; d="scan'208";a="192999836" Received: from friedlmi-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.54.26]) by orsmga002.jf.intel.com with ESMTP; 29 Aug 2019 08:39:18 -0700 Date: Thu, 29 Aug 2019 18:39:17 +0300 From: Jarkko Sakkinen To: Seunghun Han Cc: Matthew Garrett , 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: <20190829153917.glq6eoka2eufy42w@linux.intel.com> References: <20190826081752.57258-1-kkamagui@gmail.com> <20190827171106.owkvt6slwwg5ypyl@srcf.ucam.org> <20190829153437.gjcqfolsc26vyt4x@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190829153437.gjcqfolsc26vyt4x@linux.intel.com> 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 Thu, Aug 29, 2019 at 06:34:37PM +0300, Jarkko Sakkinen wrote: > On Wed, Aug 28, 2019 at 06:36:04PM +0900, Seunghun Han wrote: > > > > > > On Wed, Aug 28, 2019 at 01:36:30AM +0900, Seunghun Han wrote: > > > > > > > I got your point. Is there any problem if some regions which don't > > > > need to be handled in NVS area are saved and restored? If there is a > > > > problem, how about adding code for ignoring the regions in NVS area to > > > > the nvs.c file like Jarkko said? If we add the code, we can save and > > > > restore NVS area without driver's interaction. > > > > > > The only thing that knows which regions should be skipped by the NVS > > > driver is the hardware specific driver, so the TPM driver needs to ask > > > the NVS driver to ignore that region and grant control to the TPM > > > driver. > > > > > > -- > > > Matthew Garrett | mjg59@srcf.ucam.org > > > > Thank you, Matthew and Jarkko. > > It seems that the TPM driver needs to handle the specific case that > > TPM regions are in the NVS. I would make a patch that removes TPM > > regions from the ACPI NVS by requesting to the NVS driver soon. > > > > Jarkko, > > I would like to get some advice on it. What do you think about > > removing TPM regions from the ACPI NVS in TPM CRB driver? If you don't > > mind, I would make the patch about it. > > I'm not sure if ignoring is right call. Then the hibernation behaviour > for TPM regions would break. > > Thus, should be "ask access" rather than "grant control". Or "reserve access" as NVS driver does not have intelligence to do any policy based decision here. A function that gets region and then checks if NVS driver has matching one and returns true/false based on that should be good enough. Then you raw ioremap() in the TPM driver. /Jarkko