Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp375575ybb; Wed, 1 Apr 2020 01:35:25 -0700 (PDT) X-Google-Smtp-Source: APiQypJqGgN/A4Ytok+20J9WgZkLjMGzQkJsO7qn8xkq4QaX4wp/Jd6EbnaoVf0CEfViz6brG5Qq X-Received: by 2002:aca:eb4e:: with SMTP id j75mr2073998oih.18.1585730125101; Wed, 01 Apr 2020 01:35:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585730125; cv=none; d=google.com; s=arc-20160816; b=fpdhp5mpIHs3SWp9c6gwhnZ71rlNpFbWe9hYOoJB/vg5vdLfK1vO4O+mU0wMpe3ia7 fchAFY3eGeD5N4Y69RvG2G/7EFl2OTLluKIigQwDUeKWu/jZ6rQH9tMYYSeWwahOvSVF 8q/xa+6Qmh9LeBEgE8Xz9BIJbx9TYwgf2XWPZbEksfH7oSkGc6SHMOAy0uDzE1eRGoDL xzoWhGLoa8LVH7FY8mnRtthWHKzzW8kkiCyAQVgrixPHy3uomdMTB+lTrLdroqwQZajU CEZUmUXUs5RQKk9Gq1rCwMYlTtmb469DXBctgdg4GBja1sQgeGZ7ACi7IgpwmKo3AIzu Fexg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=8jFXRYjHe3fcova9BcywJs+6fYX5GeZb2TwWiOJz0Ho=; b=U+J/xe4elI+6I5ILhOwg+/xpTFJU9odaaKxdsj7bG/gxKKL5V2MSXBRqZAWqptKGg6 Q8PCfNAQCn0OlXS/zLQ1Xyivo38vG1v/+bPydcbx7VGYmTepKSKdM2fSsv5NieJ5AZCr wunJwiDEfRpMCyHY/9XHWUCjYjAbuCBRce/4qm04wiWD7VYIt96RmVrUultyNeDrvmc0 D/+eX4HOdoFeXFmDyWhhI5GnDnKjwSWz5P/bqlxiCFS7Eqpl6uv3vTe3HIS+X1lbkxsD 5b3TKk9GmIhMVTzXy1IAc6TyP922324H+TL0LVhipXAzwio9yGv+OTPw6VfdNrNFjQB3 c6GQ== 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 l15si500079otl.297.2020.04.01.01.35.11; Wed, 01 Apr 2020 01:35:25 -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 S1727723AbgDAIey (ORCPT + 99 others); Wed, 1 Apr 2020 04:34:54 -0400 Received: from mga05.intel.com ([192.55.52.43]:15300 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726197AbgDAIex (ORCPT ); Wed, 1 Apr 2020 04:34:53 -0400 IronPort-SDR: dpwCN4ZnyE65b98ycXD9yIyuRuQUBS3+frPa4m30GDpWGJUwwUs+FUw6FtWPNow7ihhoCQX3Tp f/WuJnvSTBew== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2020 01:34:52 -0700 IronPort-SDR: RwT7UXzeOcUGqE6tXf86sqPLLmf4F50xYbBKutEuAFVkKcvphl88oRCC8HKIYBSLdBOPEsfiXI 7wGE+x1ViW3g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,331,1580803200"; d="scan'208";a="395879471" Received: from vikasjox-mobl.amr.corp.intel.com (HELO localhost) ([10.249.39.53]) by orsmga004.jf.intel.com with ESMTP; 01 Apr 2020 01:34:40 -0700 Date: Wed, 1 Apr 2020 11:34:38 +0300 From: Jarkko Sakkinen To: Benoit HOUYERE Cc: "amirmizi6@gmail.com" , "Eyal.Cohen@nuvoton.com" , "oshrialkoby85@gmail.com" , "alexander.steffen@infineon.com" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , "peterhuewe@gmx.de" , "jgg@ziepe.ca" , "arnd@arndb.de" , "gregkh@linuxfoundation.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-integrity@vger.kernel.org" , "oshri.alkoby@nuvoton.com" , "tmaimon77@gmail.com" , "gcwilson@us.ibm.com" , "kgoldman@us.ibm.com" , "Dan.Morav@nuvoton.com" , "oren.tanami@nuvoton.com" , "shmulik.hager@nuvoton.com" , "amir.mizinski@nuvoton.com" , Olivier COLLART , Yves MAGNAUD Subject: Re: [PATCH v4 4/7] tpm: tpm_tis: Fix expected bit handling and send all bytes in one shot without last byte in exception Message-ID: <20200401083438.GC17325@linux.intel.com> References: <20200331113207.107080-1-amirmizi6@gmail.com> <20200331113207.107080-5-amirmizi6@gmail.com> <20200331121720.GB9284@linux.intel.com> <19c8ae3023404ae9affcb1ce04b7ee4b@SFHDAG3NODE3.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19c8ae3023404ae9affcb1ce04b7ee4b@SFHDAG3NODE3.st.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 31, 2020 at 09:34:28PM +0000, Benoit HOUYERE wrote: > > > On Tue, Mar 31, 2020 at 02:32:04PM +0300, amirmizi6@gmail.com wrote: > > > From: Amir Mizinski > > > > > > Today, actual implementation for send massage is not correct. We check > > > and loop only on TPM_STS.stsValid bit and next we single check > > > TPM_STS.expect bit value. > > > TPM_STS.expected bit shall be checked in the same time of > > > TPM_STS.stsValid, and should be repeated until timeout_A. > > > To aquire that, "wait_for_tpm_stat" function is modified to > > > "wait_for_tpm_stat_result". this function read regulary status > > > register and check bit defined by "mask" to reach value defined in "mask_result" > > > (that way a bit in mask can be checked if reached 1 or 0). > > > > > > Respectively, to send message as defined in > > > TCG_DesignPrinciples_TPM2p0Driver_vp24_pubrev.pdf, all bytes should be > > > sent in one shot instead of sending last byte in exception. > > > > > > This improvment was suggested by Benoit Houyere. > > >Use suggested-by tag. > > >Also if something is not correct, please provide a fixes tag. > > > You are speaking now in theoretical level, which we don't really care that much. Is this causing you real issues? If the answer is yes, please report them. If the > >answer is no, we don't need this. > > > /Jarkko > > I2C TPM specification introduce CRC calculation on TPM command bytes. > CRC calculation take place from last byte acquired to > TPM_STS.expected bit reset (=0) .It introduces latency and actual > incorrect implementation becomes visible now under I2C on the contrary > before that's all. The case where TPM keeps TPM_STS.expected bit set > with TPM_STS.stsValid set after last byte reception is possible and is > not an issue. It's not theoretical level, it's practical level now. Thank you, think I got it. This means that it does not need a fixes tag because it does not break any hardware that it currently supported. I'd suggest refining the commit message. Not only it is somewhat loosely writte peace of text but also has typos like "massage". /Jarkko