From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCC7CC77B7A for ; Mon, 29 May 2023 10:47:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231559AbjE2KrL convert rfc822-to-8bit (ORCPT ); Mon, 29 May 2023 06:47:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231435AbjE2KrJ (ORCPT ); Mon, 29 May 2023 06:47:09 -0400 X-Greylist: delayed 123 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 29 May 2023 03:47:06 PDT Received: from sender4-of-o54.zoho.com (sender4-of-o54.zoho.com [136.143.188.54]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BD78C2; Mon, 29 May 2023 03:47:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685357075; cv=none; d=zohomail.com; s=zohoarc; b=mfYwKZkWnSyQxAG/hx8hnijLYjSP8vNivWOMWCtmLeuphfDNUwr/Nfp/TLyHFU2D8yy6dTwZjX7xRBroWnTkX96jDQPDerM10XPESXNQQEHtJl535RqAUkZMKb15+bhRUZ07ry2HDPPnCmmHTg97BNOnDD0q2TFXcxMtaydFZ78= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1685357075; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=sYJRyoaWNedAUlsFNHANGDhH65d5Kl1FWDQqvTjTZEU=; b=Sbf8LLAMsS1nxRbMk6UsDLAdbTjo1688hbxHU409NuE9KBlK7mpiKdVESir5ub7qG5+XDZO2bc+92sMulGVmKbbVdGpWRV6/zW24ykbCLbd01YgZ8PBZ5xwXnLeFwfN1CB5PwxdjVLeFZkDR5jvgzrFnDtOh9MZQ2uDpah9Bjmo= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=linux@mniewoehner.de; dmarc=pass header.from= Received: from z3r0.lan (31.187.91.190 [31.187.91.190]) by mx.zohomail.com with SMTPS id 168535707300856.57943381929772; Mon, 29 May 2023 03:44:33 -0700 (PDT) Message-ID: <5bdbf3cc3335e1de1f7c13dc79a6d48b65b9d81a.camel@mniewoehner.de> Subject: Re: [PATCH 1/2] tpm, tpm_tis: Handle interrupt storm From: Michael =?ISO-8859-1?Q?Niew=F6hner?= To: Lukas Wunner , =?ISO-8859-1?Q?P=E9ter?= Ujfalusi Cc: Lino Sanfilippo , peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca, jsnitsel@redhat.com, hdegoede@redhat.com, oe-lkp@lists.linux.dev, lkp@intel.com, peterz@infradead.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, l.sanfilippo@kunbus.com, p.rosenberger@kunbus.com In-Reply-To: <20230523151642.GA31298@wunner.de> References: <20230522143105.8617-1-LinoSanfilippo@gmx.de> <20230523074443.GA21236@wunner.de> <98f7dc1a-6bed-a66f-650e-10caeb7d0bca@linux.intel.com> <20230523151642.GA31298@wunner.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Mon, 29 May 2023 12:44:28 +0200 MIME-Version: 1.0 User-Agent: Evolution 3.44.4 X-ZohoMailClient: External Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2023-05-23 at 17:16 +0200, Lukas Wunner wrote: > > > > > +       dev_err(&chip->dev, HW_ERR > > > > > +               "TPM interrupt storm detected, polling instead\n"); > > > > > > > > Should this be dev_warn or even dev_info level? > > > > > > The corresponding message emitted in tpm_tis_core_init() for > > > an interrupt that's *never* asserted uses dev_err(), so using > > > dev_err() here as well serves consistency: > > > > > >         dev_err(&chip->dev, FW_BUG > > >                 "TPM interrupt not working, polling instead\n"); > > > > > > That way the same severity is used both for the never asserted and > > > the never deasserted interrupt case. > > > > Oh, OK. > > Is there anything the user can do to have a ERROR less boot? > > You're right that the user can't do anything about it and that > toning the message down to KERN_WARN or even KERN_NOTICE severity > may be appropriate. > > However the above-quoted message for the never asserted interrupt > in tpm_tis_core_init() should then likewise be toned down to the > same severity. > > I'm wondering why that message uses FW_BUG.  That doesn't make any > sense to me.  It's typically not a firmware bug, but a hardware issue, > e.g. an interrupt pin may erroneously not be connected or may be > connected to ground.  Lino used HW_ERR, which seems more appropriate > to me. Firmware is responsible for configuring gpios and interrupts correctly, independently of it being a design decision or a mistake. AIUI any interrupt storm could be prevented by firmware in any case by simply disabling that interrupt. Thus, FW_BUG is the right thing to use here IMO.