[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170116134612.uuzbb6xi7pw7czyo@intel.com>
Date: Mon, 16 Jan 2017 15:46:12 +0200
From: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To: "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc: tpmdd-devel@...ts.sourceforge.net,
linux-kernel <linux-kernel@...r.kernel.org>,
Peter Huewe <peterhuewe@....de>,
Marcel Selhorst <tpmdd@...horst.net>,
Christophe Ricard <christophe.ricard@...il.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Subject: Re: [PATCH] tpm_tis: use default timeout value if chip reports it as
zero
On Mon, Jan 16, 2017 at 11:42:02AM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 13, 2017 at 10:37:00PM +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.
> > The initialization proceeds fine until we get and start using chip-reported
> > timeouts - and the chip reports C and D timeouts of zero.
> >
> > It turns out that until commit 8e54caf407b98e ("tpm: Provide a generic
> > means to override the chip returned timeouts") we had actually let default
> > timeout values remain in this case, so let's bring back this behavior to
> > make chips like Atmel 3203 work again.
> >
> > Use a common code that was introduced by that commit so a warning is
> > printed in this case and /sys/class/tpm/tpm*/timeouts correctly says the
> > timeouts aren't chip-original.
> >
> > Signed-off-by: Maciej S. Szmigiero <mail@...iej.szmigiero.name>
> >
> > Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM access")
> > Cc: stable@...r.kernel.org
>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
It's now applied to my master branch so if someone wants to
test it, it should be fairly easy.
/Jarkko
Powered by blists - more mailing lists