Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753633AbcJKSUz convert rfc822-to-8bit (ORCPT ); Tue, 11 Oct 2016 14:20:55 -0400 Received: from mout.gmx.net ([212.227.15.18]:50678 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753434AbcJKSUw (ORCPT ); Tue, 11 Oct 2016 14:20:52 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <20161011171313.GD6881@obsidianresearch.com> References: <1476187261-29027-1-git-send-email-jarkko.sakkinen@linux.intel.com> <20161011171313.GD6881@obsidianresearch.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH] char/tpm: Check return code of wait_for_tpm_stat From: Peter Huewe Date: Tue, 11 Oct 2016 20:01:09 +0200 To: Jason Gunthorpe , Jarkko Sakkinen CC: tpmdd-devel@lists.sourceforge.net, Marcel Selhorst , open list Message-ID: <9174B547-9CD1-4F1B-A2A7-38B9A6AA3B33@gmx.de> X-Provags-ID: V03:K0:Vd2b3jkVbnjHRy6yDXVmfaLOH3mWbPqf7BF5OSFcjdbn8mX9y+8 sU+r0P1MGIbDmBmmjIbd6DD7BkPBZTV6VJWWKlg3tD62mZm5vm6xoU3iv92XVcgnUnr3iI6 dAeNUQZzD8AaVfRu1e9q4ewPbyNR4Etbr/UcoTi5FNK7/8+PHmiJL2M5/Vsnm9v1q2h+Azg b4WyunuqlwSQ/YdCExFPA== X-UI-Out-Filterresults: notjunk:1;V01:K0:42y8R8t4k1Y=:OPtBLWTErHRT8Z31LVsQ7D 9luSqd9pRw2Oqcck4zr6I9+2ejFYQTvKrmCrhkfyL4IcSYlTS+FQLl0TlsM+rHEPJ/HOQOVB8 TSQ47RPMcmZ2hAiZnhM34OQnp9oUtnDYMVegpM/0ZSl46uqR92oqF5zFMS138u9BJodcJdnGp RpDEUDp4Mtx8B5/UPvc1y4yULj+3iGvwN0LO3g22sGQP2gn8wM2+eCprlW2ZlETkAf66k9eOZ hMOr6lw+rrBnQpr6B2NLcxVuNposKkr1pglEdLt0T+jmKXBxT2CFO+G7BppOixrDc/cz573+7 Hmu/9P7AXEjGiA/ffGTfwLjK+tXqgfdePUrYU6ltlI9qlNomDBNYRLGVfPOQEKDM5Jz7Ux891 ZWALOkU+3HY0GeNqKnSIAeewvg3+YFHGKsJKKqONuBgxjzuVQ46RlP+1f25WJebMCIVX0NYlV iXIzSciAIu7yV5UoU1RwTKZ+2WxBUe9Qp9WZ327sJxzNEpeca7BUKZRaN1dF5OjrHoBACr70Z FjbWx2AF3fMx9kY5fnuyqEUmlufrVGuqRZWRpfrcEv3XXFqV8QwKdBrCoiYVANgrv1AET/HF6 9s0JpXa4QwGQeLjb8NluaJWuvgw6hXaQGOo9XXBEizSxZO1NlTS4y6/ldpdAtRJk9MIzFE09W E5pW6uAWNdCOrbS1p7ZqFgJvJec1TelR3Ood+ka8kRiFfv8csJQgWugQ/mU/uy/yD4bZtsHH3 fr0AU1G5mQX3NRBza92Ltdvpyvg5R4u5e0RrjvfOi2vnpAKYwrSTJZ5w6TwDDyvdp+m5Y0WMV bLSaEMq Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1227 Lines: 29 Hi Am 11. Oktober 2016 19:13:13 MESZ, schrieb Jason Gunthorpe : >On Tue, Oct 11, 2016 at 03:01:01PM +0300, Jarkko Sakkinen wrote: >> From: Peter Huewe >> >> 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. Peter -- Sent from my mobile