On Wed, 2018-07-11 at 22:51 +0200, Peter Huewe wrote: > > Am 11. Juli 2018 22:39:05 MESZ schrieb James Bottomley <James.Bottoml > ey@xxxxxxxxxxxxxxxxxxxxx>: > > On Wed, 2018-07-11 at 14:01 -0600, Jason Gunthorpe wrote: > > > On Wed, Jul 11, 2018 at 12:08:53PM -0700, James Bottomley wrote: > > > > On Wed, 2018-07-11 at 12:21 -0600, Jason Gunthorpe wrote: [...] > > > > > I wonder if something about triggering ETIME even once breaks > > > > > the driver so it can't talk to the chip at all thereafter.. > > > > > > > > > > Ie it doesn't abort the command properly and becomes desynced > > > > > with the TIS execution protocol. > > > > > > > > Yes, I wondered about this, but I don't understand the bus > > > > protocol well enough. The tpm-interface:tpm_try_transmit() > > > > which throws the first ETIME says after we get that we send > > > > chip->ops->cancel() which tpm_tis simply translates to > > > > tpm_tis_ready() which also times out. Is there a bigger hammer > > > > I can hit it with? > > > > > > I don't remember off hand.. But this is, IMHO, a better guess > > > than the firmware crashes from reading the status register.. > > > > Oh, actually, I think the bus crashes or wedges, not the TPM. I > > just don't have any tools to probe the LPC. > > > > I doubt that your fTPM is actually attached to LPC. > And usually if lpc wedges it takes down your pc with it (from my > experience) How do I tell what it is attached to? Sysfs doesn't seem to know but I assume the ACPI information should contain something relevant. > I wonder what the contents of the acc and sts registers actually are. > > > If you want i can send you a small tis 'debug' tool tomorrow. Sure, that would help ... I'm just leafing through the TIS manual now to see if there's anything I can build into the driver. James
