Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1739862ybl; Thu, 19 Dec 2019 02:09:46 -0800 (PST) X-Google-Smtp-Source: APXvYqy3x5vOOTHFYDK2zbY+utU0ONAQ4GLkwMsIvdkcEaI0hDCJDT+7eBeBMIeJLLJ9QFXQXu0B X-Received: by 2002:a9d:478:: with SMTP id 111mr7867827otc.359.1576750185926; Thu, 19 Dec 2019 02:09:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576750185; cv=none; d=google.com; s=arc-20160816; b=EY4cMkvRHQW7GUwWNCeLQRCWvLv0kOx8L8Uy29idOvI35eWfidlXGdu4szUjNkMgJe PUOEsxSVlabw8uFgxxh7Kd5TNgg+yWpUKTjrFuHEp/WPEDPbHYr6mowN0MdWJwyvtX21 eSaRYfa3sMUbDqV/vFcJA00sTOIJyiD25Tvy2KTDSYOBO13lHO1mWX63z92VNq2hBwkx qWKKLedWmRCJUHUco9w3+e7BZlfemA16oeY4CBWht3w2Px3pMUgV4+OEop1iAHACliX0 zeXvThy0gqTOKr0qRFeHcgDq47+vGA40uTXmDQEPb0zy4yFUnSmfhtuYtv/XAv8aeJCL mLLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:mail-followup-to:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=l5IEbrYkGbA+uzv9F0SWz6YFiqb5Twn8DMBOAdSn76Y=; b=kZd/kCu/98SvIi/JtLAHauuHAYCL6FOE4Y07T2X4ButenhUJQlqR/DU8KNCyULQYXu WDi8x6BRRD0DnmWQazj0MTkpR6buGs5MoISt1vdUvAamXg4rJyDLuRXid5L2tlzbo6uT TzcuPyJsEJ1azmUevhKahHr+351bb5/Jq1l1+58yGBMqjxRJpnnWYihO0LqerzaRKdA4 CnS4WV5lQrNKWWO7fPTnKU2fhbTuQKJMbfisSYSET+KB30LevGzN4Q17hxg1c7uEy+wu Pr8Lbd8Ooslj2LUvNZKHPUJy2X3FW6YkRza/03xSjlnaAFPyMkvSC9Hy+k8V8MbtYkUb UqSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="KTho/DVi"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si3005308oth.182.2019.12.19.02.09.33; Thu, 19 Dec 2019 02:09:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="KTho/DVi"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726770AbfLSKIJ (ORCPT + 99 others); Thu, 19 Dec 2019 05:08:09 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:56753 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726759AbfLSKII (ORCPT ); Thu, 19 Dec 2019 05:08:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1576750087; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=l5IEbrYkGbA+uzv9F0SWz6YFiqb5Twn8DMBOAdSn76Y=; b=KTho/DViCc5AWl1AGQcI7ufSxZF4Ava155m0ykf6ynt5nHq2ddW+w/eHdRgySS0AWNjlv2 4c6pFwhf8IvCwY15Fo8+4oN2/MICbPfCDq8oYovJmkQEcnVtrl6WuPrPD3jsYSHI29B+aK abFfNk77+TA5+UBT0pTdXa1bvOmwgN0= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-71-LYut9MbhNLSAp9WcIvklOg-1; Thu, 19 Dec 2019 05:07:55 -0500 X-MC-Unique: LYut9MbhNLSAp9WcIvklOg-1 Received: by mail-qk1-f199.google.com with SMTP id a6so639565qkl.7 for ; Thu, 19 Dec 2019 02:07:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=l5IEbrYkGbA+uzv9F0SWz6YFiqb5Twn8DMBOAdSn76Y=; b=hdOwNMqJvV1rClDXC2darqftIS10a6ETJd7uX6p94cCclOzBaAw33KNjadAex8lMQA +FII1G1wjFtNxDfTRP562aWgLFABYe8sflfT2ZKLl4fey+qQygMRGkhsArgR9x+0H/yf aqQZu+tWOERgQWVr8u8mI7Ngt6ictiSbwGxMyStyjEo8V9Pmwchjqqm8W5itHiIADzdh xmGCbqQ1aOkrPcRbk8FHkC9vO/SpXVIHtkAlg+UA5+2Ur+mBG9Az9+JRixJKCun1mF74 qaryuC7rj7VwtYSUR1PIyfx5ZB3ByGbYHudcK98IZzOY5B68DLLuRfI91kQngqPU2Erw buyA== X-Gm-Message-State: APjAAAVkwBCPFiKfIPqFh2PBxtcTGhRGwzpTAqNREKEEAlxnISnA+xvt fYwM0gKYyHOjUK70GHpKkoh1nDGsFxyfyzSAKKR+P7qNwSbeoUElH6soBDKuGD2/4D71woezvH/ 95C6HW/nHNSxP2HzOZ+AqbHtC X-Received: by 2002:a05:6214:1150:: with SMTP id b16mr6773874qvt.71.1576750075526; Thu, 19 Dec 2019 02:07:55 -0800 (PST) X-Received: by 2002:a05:6214:1150:: with SMTP id b16mr6773857qvt.71.1576750075235; Thu, 19 Dec 2019 02:07:55 -0800 (PST) Received: from localhost (ip70-163-223-149.ph.ph.cox.net. [70.163.223.149]) by smtp.gmail.com with ESMTPSA id w21sm1769397qth.17.2019.12.19.02.07.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Dec 2019 02:07:54 -0800 (PST) Date: Thu, 19 Dec 2019 03:07:47 -0700 From: Jerry Snitselaar To: Dan Williams Cc: Jarkko Sakkinen , Linux Kernel Mailing List , Christian Bundy , Peter Huewe , Jason Gunthorpe , Stefan Berger , stable , linux-integrity@vger.kernel.org Subject: Re: [PATCH v2] tpm_tis: reserve chip for duration of tpm_tis_core_init Message-ID: <20191219100747.fhbqmzk7xby3tt3l@cantor> Reply-To: Jerry Snitselaar Mail-Followup-To: Dan Williams , Jarkko Sakkinen , Linux Kernel Mailing List , Christian Bundy , Peter Huewe , Jason Gunthorpe , Stefan Berger , stable , linux-integrity@vger.kernel.org References: <20191211231758.22263-1-jsnitsel@redhat.com> <20191211235455.24424-1-jsnitsel@redhat.com> <5aef0fbe28ed23b963c53d61445b0bac6f108642.camel@linux.intel.com> <20191217020022.knh7uxt4pn77wk5m@cantor> <5d0763334def7d7ae1e7cf931ef9b14184dce238.camel@linux.intel.com> <20191217171844.huqlj5csr262zkkk@cantor> <37f4ed0d6145dbe1e8724a5d05d0da82b593bf9c.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed Dec 18 19, Dan Williams wrote: >On Wed, Dec 18, 2019 at 3:07 PM Jarkko Sakkinen > wrote: >> >> On Tue, 2019-12-17 at 10:18 -0700, Jerry Snitselaar wrote: >> > On Tue Dec 17 19, Jarkko Sakkinen wrote: >> > > On Mon, 2019-12-16 at 18:14 -0800, Dan Williams wrote: >> > > > On Mon, Dec 16, 2019 at 6:00 PM Jerry Snitselaar wrote: >> > > > > On Mon Dec 16 19, Dan Williams wrote: >> > > > > > On Mon, Dec 16, 2019 at 4:59 PM Jarkko Sakkinen >> > > > > > wrote: >> > > > > > > On Wed, 2019-12-11 at 16:54 -0700, Jerry Snitselaar wrote: >> > > > > > > > Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when >> > > > > > > > issuing commands to the tpm during initialization, just reserve the >> > > > > > > > chip after wait_startup, and release it when we are ready to call >> > > > > > > > tpm_chip_register. >> > > > > > > > >> > > > > > > > Cc: Christian Bundy >> > > > > > > > Cc: Dan Williams >> > > > > > > > Cc: Peter Huewe >> > > > > > > > Cc: Jarkko Sakkinen >> > > > > > > > Cc: Jason Gunthorpe >> > > > > > > > Cc: Stefan Berger >> > > > > > > > Cc: stable@vger.kernel.org >> > > > > > > > Cc: linux-integrity@vger.kernel.org >> > > > > > > > Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") >> > > > > > > > Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's") >> > > > > > > > Signed-off-by: Jerry Snitselaar >> > > > > > > >> > > > > > > I pushed to my master with minor tweaks and added my tags. >> > > > > > > >> > > > > > > Please check before I put it to linux-next. >> > > > > > >> > > > > > I don't see it yet here: >> > > > > > >> > > > > > http://git.infradead.org/users/jjs/linux-tpmdd.git/shortlog/refs/heads/master >> > > > > > >> > > > > > However, I wanted to make sure you captured that this does *not* fix >> > > > > > the interrupt issue. I.e. make sure you remove the "Fixes: >> > > > > > 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's")" >> > > > > > tag. >> > > > > > >> > > > > > With that said, are you going to include the revert of: >> > > > > > >> > > > > > 1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts >> > > > > >> > > > > Dan, with the above reverted do you still get the screaming interrupt? >> > > > >> > > > Yes, the screaming interrupt goes away, although it is replaced by >> > > > these messages when the driver starts: >> > > > >> > > > [ 3.725131] tpm_tis IFX0740:00: 2.0 TPM (device-id 0x1B, rev-id 16) >> > > > [ 3.725358] tpm tpm0: tpm_try_transmit: send(): error -5 >> > > > [ 3.725359] tpm tpm0: [Firmware Bug]: TPM interrupt not working, >> > > > polling instead >> > > > >> > > > If the choice is "error message + polled-mode" vs "pinning a cpu with >> > > > interrupts" I'd accept the former, but wanted Jarkko with his >> > > > maintainer hat to weigh in. >> > > > >> > > > Is there a simple sanity check I can run to see if the TPM is still >> > > > operational in this state? >> > > >> > > What about T490S? >> > > >> > > /Jarkko >> > > >> > >> > Hi Jarkko, I'm waiting to hear back from the t490s user, but I imagine >> > it still has the problem as well. >> > >> > Christian, were you able to try this patch and verify it still >> > resolves the issue you were having with the kernel failing to get the >> > timeouts and durations from the tpm? >> >> Including those reverts would be a bogus change at this point. > >I'm failing to see how you arrived at that conclusion. > >> The fix that I already applied obviously fixes an issue even if >> it does not fix all the issues. > >These patches take a usable system and make it unusable: > >1ea32c83c699 tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts >5b359c7c4372 tpm_tis_core: Turn on the TPM before probing IRQ's > >...they need to be reverted, or the regression needs to be fixed, but >asserting that you fixed something else unrelated does not help. > Reverting 1ea32c83c699 ("tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts") would at least allow people impacted by this to boot their systems without disabling the tpm, or blacklisting the module while we figure this out. From what I can tell the tpm_tis code was operating in that state since 570a36097f30 ("tpm: drop 'irq' from struct tpm_vendor_specific") until Stefan's patch. Regards, Jerry