From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH] tpm_tis: override reported C and D timeouts for Atmel 3203 Date: Thu, 12 Jan 2017 11:42:29 -0700 Message-ID: <20170112184229.GB12836@obsidianresearch.com> References: <08953fb6-c332-ef29-2614-6335570023be@maciej.szmigiero.name> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <08953fb6-c332-ef29-2614-6335570023be-APzI5cXaD1zVlRWJc41N0YvC60bnQu0Y@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: "Maciej S. Szmigiero" Cc: Christophe Ricard , linux-kernel , tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: tpmdd-devel@lists.sourceforge.net On Thu, Jan 12, 2017 at 07:08:53PM +0100, Maciej S. Szmigiero wrote: > Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM > access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9) no > longer works. > It turns out the initialization proceeds fine until we get and start using > chip-reported timeouts - and the chip reports C and D timeouts of zero. > > Since these are clearly not long enough let's add an override for them > to TPM TIS default values, just as we do for Atmel 3204. > A and B timeouts are set to the same values as the chip normally reports. > > Signed-off-by: Maciej S. Szmigiero > static const struct tis_vendor_timeout_override vendor_timeout_overrides[] = { > + /* Atmel 3203 */ > + { 0x32031114, { (10*1000), (10*1000), > + (TIS_SHORT_TIMEOUT*1000), (TIS_SHORT_TIMEOUT*1000) } }, > /* Atmel 3204 */ > { 0x32041114, { (TIS_SHORT_TIMEOUT*1000), (TIS_LONG_TIMEOUT*1000), > (TIS_SHORT_TIMEOUT*1000), (TIS_SHORT_TIMEOUT*1000) } }, Can you also add a check for 0 timeouts in the core code and print a FW_BUG :\ Jason ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751242AbdALSmf (ORCPT ); Thu, 12 Jan 2017 13:42:35 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:37419 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751213AbdALSme (ORCPT ); Thu, 12 Jan 2017 13:42:34 -0500 Date: Thu, 12 Jan 2017 11:42:29 -0700 From: Jason Gunthorpe To: "Maciej S. Szmigiero" Cc: tpmdd-devel@lists.sourceforge.net, linux-kernel , Peter Huewe , Marcel Selhorst , Jarkko Sakkinen , Christophe Ricard Subject: Re: [PATCH] tpm_tis: override reported C and D timeouts for Atmel 3203 Message-ID: <20170112184229.GB12836@obsidianresearch.com> References: <08953fb6-c332-ef29-2614-6335570023be@maciej.szmigiero.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08953fb6-c332-ef29-2614-6335570023be@maciej.szmigiero.name> User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 12, 2017 at 07:08:53PM +0100, Maciej S. Szmigiero wrote: > Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM > access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9) no > longer works. > It turns out the initialization proceeds fine until we get and start using > chip-reported timeouts - and the chip reports C and D timeouts of zero. > > Since these are clearly not long enough let's add an override for them > to TPM TIS default values, just as we do for Atmel 3204. > A and B timeouts are set to the same values as the chip normally reports. > > Signed-off-by: Maciej S. Szmigiero > static const struct tis_vendor_timeout_override vendor_timeout_overrides[] = { > + /* Atmel 3203 */ > + { 0x32031114, { (10*1000), (10*1000), > + (TIS_SHORT_TIMEOUT*1000), (TIS_SHORT_TIMEOUT*1000) } }, > /* Atmel 3204 */ > { 0x32041114, { (TIS_SHORT_TIMEOUT*1000), (TIS_LONG_TIMEOUT*1000), > (TIS_SHORT_TIMEOUT*1000), (TIS_SHORT_TIMEOUT*1000) } }, Can you also add a check for 0 timeouts in the core code and print a FW_BUG :\ Jason