From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752564AbdLGShv (ORCPT ); Thu, 7 Dec 2017 13:37:51 -0500 Received: from mail-wr0-f193.google.com ([209.85.128.193]:40641 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752483AbdLGSht (ORCPT ); Thu, 7 Dec 2017 13:37:49 -0500 X-Google-Smtp-Source: AGs4zMZpvfLnyjoxfr/3swLMfJHpgJL67be9A624pYYu3U3Rty/VqqD+aJr+YEVXNrzzxlFHLpLtRQ== Date: Thu, 7 Dec 2017 11:37:43 -0700 From: Jason Gunthorpe To: Alexander.Steffen@infineon.com Cc: pmenzel@molgen.mpg.de, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest` Message-ID: <20171207183743.GB16884@ziepe.ca> References: <32b0e6c1292f4818825e9e0e9bff4d39@infineon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <32b0e6c1292f4818825e9e0e9bff4d39@infineon.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 07, 2017 at 03:56:07PM +0000, Alexander.Steffen@infineon.com wrote: > > If these are intentional, it’d be great > > to give some hint to the user, what effect this has. > > I agree that those error messages in their current form are not that > helpful for the users. But they are part of the general driver > architecture, and are also caused by other parts of the code > (e.g. when using a TPM 1.2 that is deactivated or when the platform > did not send a startup command). We should find a way to hide (or at > least mark) those kind of expected errors. Other parts of the TPM code did supresses 'expected' errors like this, I'm not sure if it got removed during Jarkko's cleanup though - we need to put stuff like that back, it should not printk for something like this. For this, if we are waiting then it should compute an absolute time after which it will give up. Code it like this instead and get rid of the ugly 'duration' scheme. ktime_t stop = ktime_add_ns(ktime_get(), [timeout in ns]); do { } while (ktime_before(ktime_get(), stop); Jason