From patchwork Fri Nov 20 13:32:34 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Wilck X-Patchwork-Id: 546923 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.sourceforge.net (lists.sourceforge.net [216.34.181.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id CFA7B1402A9 for ; Sat, 21 Nov 2015 00:33:05 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=sfs-ml-2.v29.ch3.sourceforge.com) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ZzloD-0002XY-4F; Fri, 20 Nov 2015 13:33:01 +0000 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ZzloC-0002XP-BT for tpmdd-devel@lists.sourceforge.net; Fri, 20 Nov 2015 13:33:00 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of ts.fujitsu.com designates 80.70.172.49 as permitted sender) client-ip=80.70.172.49; envelope-from=martin.wilck@ts.fujitsu.com; helo=dgate10.ts.fujitsu.com; Received: from dgate10.ts.fujitsu.com ([80.70.172.49]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1ZzloB-0003TO-C4 for tpmdd-devel@lists.sourceforge.net; Fri, 20 Nov 2015 13:33:00 +0000 X-SBRSScore: None Received: from unknown (HELO abgdgate60u.abg.fsc.net) ([172.25.138.90]) by dgate10u.abg.fsc.net with ESMTP; 20 Nov 2015 14:32:45 +0100 Received: from unknown (HELO pdbcooper.pdb.fsc.net) ([172.25.111.126]) by abgdgate60u.abg.fsc.net with ESMTP; 20 Nov 2015 14:32:45 +0100 Received: from pdbcooper.pdb.fsc.net (localhost [127.0.0.1]) by pdbcooper.pdb.fsc.net (8.14.9/8.14.8) with ESMTP id tAKDWdup006845; Fri, 20 Nov 2015 14:32:40 +0100 From: martin.wilck@ts.fujitsu.com To: tpmdd-devel@lists.sourceforge.net Date: Fri, 20 Nov 2015 14:32:34 +0100 Message-Id: <1448026354-6807-6-git-send-email-martin.wilck@ts.fujitsu.com> X-Mailer: git-send-email 2.1.0 In-Reply-To: <1448026354-6807-1-git-send-email-martin.wilck@ts.fujitsu.com> References: <20151105170005.GA11530@intel.com> <1448026354-6807-1-git-send-email-martin.wilck@ts.fujitsu.com> X-Spam-Score: -2.2 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1ZzloB-0003TO-C4 Cc: Martin Wilck Subject: [tpmdd-devel] [PATCH 5/5] tpm_tis: don't use IRQF_SHARED by default when probing IRQ X-BeenThere: tpmdd-devel@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: Tpm Device Driver maintainance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: tpmdd-devel-bounces@lists.sourceforge.net From: Martin Wilck When probing IRQs, IRQF_SHARED may cause IRQs to be falsely detected if other devices generate IRQ events while tpm_tis is probing or testing. I have seen this on my test machine repeatedly. The sequence of events in the errror case is as follows: 1 TPM IRQ generation is enabled for IRQ X and test command sent 2 TPM finishes command and sets data ready / IRQ flags, but the IRQ doesn't arrive because it's not configured in the system. Normally this would cause a timeout and the IRQ would be found not to work, but... 3 The other device triggers an IRQ X, causing tis_int_probe() to get called and find the IRQ flags set. Now we conclude that the IRQ seems to work, with is wrong. It is impossible to distinguish this condition from a case where the TPM IRQ actually worked. Therefore, refrain from probing IRQs that are already used by other devices by default. Use "interrupts=2" module parameter to obtain the previous behavior. v2: Add better explanation in commit message. Signed-off-by: Martin Wilck --- drivers/char/tpm/tpm_tis.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c index 360bccc..54d9080 100644 --- a/drivers/char/tpm/tpm_tis.c +++ b/drivers/char/tpm/tpm_tis.c @@ -622,9 +622,9 @@ static irqreturn_t tis_int_handler(int dummy, void *dev_id) return IRQ_HANDLED; } -static bool interrupts = true; -module_param(interrupts, bool, 0444); -MODULE_PARM_DESC(interrupts, "Enable interrupts"); +static int interrupts = 1; +module_param(interrupts, int, 0444); +MODULE_PARM_DESC(interrupts, "1 - enable interrupts (default), 0 - disable interrupts, 2 - use shared interrupts when probing"); static void tpm_tis_remove(struct tpm_chip *chip) { @@ -784,7 +784,8 @@ static int tpm_tis_init(struct device *dev, struct tpm_info *tpm_info, iowrite8(i, chip->vendor.iobase + TPM_INT_VECTOR(chip->vendor.locality)); if (devm_request_irq - (dev, i, tis_int_probe, IRQF_SHARED, + (dev, i, tis_int_probe, + interrupts == 2 ? IRQF_SHARED : 0, chip->devname, chip) != 0) { dev_info(chip->pdev, "Unable to request irq: %d for probe (this is non-fatal)\n",