Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5118777yba; Wed, 10 Apr 2019 11:44:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqyv0EJzSnW2DQYutAqhRbQl7p/DBwQxm3zU7q5Jt7LckhiBZj/sO2ZsoQ/v2fLuqgOB3CUT X-Received: by 2002:a62:e304:: with SMTP id g4mr38989787pfh.71.1554921885360; Wed, 10 Apr 2019 11:44:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554921885; cv=none; d=google.com; s=arc-20160816; b=qEwQQggQCs++3wmWTo9OYJ71ulY2XGo1bU2R4nQS4oKiV5nFvdzNeT9+8yhVSg8sfI jkLy6aXX8N7WbKfQdmhWV68Yc61if96jku03DUXje5wR+1VC+/fbRrKHYNIt8QvxWz+q I4917oduD8wV9e1dQtROTVh9Fnj94jMghJTGYIAsplvq09y9zlI9WvBW8LESrzkucaQj qtxmnXUG5inqvLBs8JkF849THZP27lnFWBP8EthKoXHwzlgCzmrFMc9hfmFlgYbySWLJ 5s2S9og1EquP5O6CRfyfNoR5kHJA2V+CJ5VelUcddB3Yg8nHkn5Z9X73rtwZDGCBjkqp y1wA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=rUYIEZPUt+2rtY6ZaeOqGIwcS5ZZJHg7t+S9vqjX8uQ=; b=EaZoDd31Us2h2z6BzpwObwgV/9iuZOjdlVJAt9AeN3VyoMJeCgXr1g5O5gh5wbdJ7p QEfNpQ7LRTa0uHTR1hZrcVkk3QOWnvLizc+ZdN+3LYkm4ysiPafbr0I+5pNdPblgwJbU HrKHaZlVoFttjd9lUXSvhxbcWxnuw8SqPS6tvY08NUJB0V7D1seGt+KsFg2Zfvul4A/J 32emyI8MAT30l35KukkEEBctW5iz2l7I8SyBr9P8e496E4IWIzGoFD/iR5Bu6och94wR dsrDUxehT2kCMzXVTXwHwfAaosUA1YqtRxVS1NKEO8nKXJp+jL77GToQM0sui5vDjmec mdIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SMHj9Y4o; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a22si32655064plm.263.2019.04.10.11.44.29; Wed, 10 Apr 2019 11:44:45 -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; dkim=pass header.i=@kernel.org header.s=default header.b=SMHj9Y4o; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387765AbfDJQTx (ORCPT + 99 others); Wed, 10 Apr 2019 12:19:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:54650 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727892AbfDJQTw (ORCPT ); Wed, 10 Apr 2019 12:19:52 -0400 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A020D2082E; Wed, 10 Apr 2019 16:19:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554913190; bh=gAg7ItIU9xtozLXCrllhDQag8IWHJgtaqRklURafv0Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SMHj9Y4oM+7mBIdPvFqy8aItw30R+O4AVPwqHZGYFZMR4HkDTGdc6x3Q/A+dtx0Og ajH22d5Rz27Dz6oVAua0tCAkEoofBBhsA/WwXeJhD6jCTFuFsJrG3gsLfjGYDN+9aw qCKs1gLi0/KJ6SaIDbduj/sbublgzhk4W2H93HrE= Date: Wed, 10 Apr 2019 12:19:49 -0400 From: Sasha Levin To: Rob Herring Cc: Peter Huewe , Jarkko Sakkinen , jgg@ziepe.ca, Mark Rutland , Jonathan Corbet , Arnd Bergmann , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , Linux Doc Mailing List , linux-integrity@vger.kernel.org, linux-kernel@microsoft.com, thiruan@microsoft.com, bryankel@microsoft.com Subject: Re: [PATCH v2 1/3] ftpm: dt-binding: add dts documentation for fTPM driver Message-ID: <20190410161949.GC11568@sasha-vm> References: <20190409184958.7476-1-sashal@kernel.org> <20190409184958.7476-2-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 09, 2019 at 04:18:29PM -0500, Rob Herring wrote: >On Tue, Apr 9, 2019 at 1:50 PM Sasha Levin wrote: >> >> The parameters are similar to the ones used by IBM's vTPM and the >> various I2C tpm drivers. > >Bindings describe h/w (or firmware interfaces in this case), not drivers. > >> >> Signed-off-by: Sasha Levin >> --- >> .../bindings/security/tpm/tpm_ftpm_tee.txt | 13 +++++++++++++ >> .../devicetree/bindings/vendor-prefixes.txt | 1 + >> 2 files changed, 14 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt >> >> diff --git a/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt b/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt >> new file mode 100644 >> index 000000000000..20fca67a56c4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/security/tpm/tpm_ftpm_tee.txt >> @@ -0,0 +1,13 @@ >> +Required properties: >> +- compatible: should be "microsoft,ftpm" >> +- linux,sml-base: 64-bit base address of the reserved memory allocated >> + for the firmware event log >> +- linux,sml-size: size of the memory allocated for the firmware event log > >Firmware is defining linux specific properties? What if I want to run >BSD? We should use 'reg' here instead. This is based on already existing code that defines these names, see tpm_read_log_of() in drivers/char/tpm/eventlog/of.c . These properties were described similarily by other interfaces (see Documentation/devicetree/bindings/security/tpm/ibmvtpm.txt or Documentation/devicetree/bindings/security/tpm/tpm-i2c.txt for example). We could rename them all if you'd like, I was just trying to follow the existing code. >What memory is used here? This should be under /reserved-memory if it >is part of "main" memory. That's my understanding, yes. >Really, I'd prefer to not see this in DT at all. Make the firmware >discoverable. Why repeat the mistakes of non-discoverable h/w in s/w >interfaces? OP-Tee at least has defined a mechanism to enumerate TEE >functions IIRC. Sadly the firmware already exists as-is on live hardware, there is a paper describing it back from 2016 and we're stuck having to support that. -- Thanks, Sasha