On Tue, Oct 11, 2016 at 08:01:09PM +0200, Peter Huewe wrote: > > > Hi > Am 11. Oktober 2016 19:13:13 MESZ, schrieb Jason Gunthorpe > <jguntho...@obsidianresearch.com>: > >On Tue, Oct 11, 2016 at 03:01:01PM +0300, Jarkko Sakkinen wrote: > >> From: Peter Huewe <peterhu...@gmx.de> > >> > >> In some weird cases it might be possible that the TPM does not set > >> STS.VALID within the given timeout time (or ever) but sets STS.EXPECT > >> (STS=0x0C) In this case the driver gets stuck in the while loop of > >> tpm_tis_send_data and loops endlessly. > > > >Doesn't that exchange mean the TPM has lost synchronization with the > >driver? Or maybe it crashed executing a command or something.. > > I saw that in the field on quite a few (similar) systems with our lpc tpms - > so it affects end users. > Yes it is caused by some desynchronization or something similar. > > If you manually send a commandReady by mmaping the memory region you can > un-stuck the driver and the situation was never seen again on that system. > > The exact reason how this happens is yet unknown, but the driver should > definitely not be stuck in an endless loop (which zombies the application > too) in that case but bail out as defined in the TIS protocol. The next > access sends the cr which cures the unsynchronization.
Even as a sanity check return codes should be checked so in any case I leaned towards applying this patch. It makes the driver more robust. /Jarkko
