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