From patchwork Wed Dec 2 19:11:55 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Gunthorpe X-Patchwork-Id: 551671 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 5A2D2140281 for ; Thu, 3 Dec 2015 06:12:15 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=sfs-ml-1.v29.ch3.sourceforge.com) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1a4Cow-0004rA-UL; Wed, 02 Dec 2015 19:12:06 +0000 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1a4Cov-0004r2-Ja for tpmdd-devel@lists.sourceforge.net; Wed, 02 Dec 2015 19:12:05 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of obsidianresearch.com designates 184.70.90.242 as permitted sender) client-ip=184.70.90.242; envelope-from=jgunthorpe@obsidianresearch.com; helo=quartz.orcorp.ca; Received: from quartz.orcorp.ca ([184.70.90.242]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1a4Cot-0006UB-P6 for tpmdd-devel@lists.sourceforge.net; Wed, 02 Dec 2015 19:12:05 +0000 Received: from [10.0.0.160] (helo=jggl.edm.orcorp.ca) by quartz.orcorp.ca with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1a4Col-0006NK-8i; Wed, 02 Dec 2015 12:11:55 -0700 Received: from jgg by jggl.edm.orcorp.ca with local (Exim 4.84) (envelope-from ) id 1a4Col-0001UJ-4E; Wed, 02 Dec 2015 12:11:55 -0700 Date: Wed, 2 Dec 2015 12:11:55 -0700 From: Jason Gunthorpe To: Jarkko Sakkinen Message-ID: <20151202191155.GA2832@obsidianresearch.com> References: <1448996309-15220-1-git-send-email-jgunthorpe@obsidianresearch.com> <20151201213351.GC5071@intel.com> <20151202182726.GB30972@obsidianresearch.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20151202182726.GB30972@obsidianresearch.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.160 X-Spam-Score: -1.1 (-) 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_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -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.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1a4Cot-0006UB-P6 Cc: Martin Wilck , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Subject: Re: [tpmdd-devel] [PATCH v2 0/3] tpm_tis: Clean up force module parameter 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: , Errors-To: tpmdd-devel-bounces@lists.sourceforge.net On Wed, Dec 02, 2015 at 11:27:27AM -0700, Jason Gunthorpe wrote: > I'm guessing that if the driver probe order is tpm_crb,tpm_tis then > things work because tpm_crb will claim the device first? Otherwise > tpm_tis claims these things unconditionally? If the probe order is > reversed things become broken? Okay, I didn't find the is_fifo before, so that make sense But this: > What is the address tpm_tis should be using? I see two things, it > either uses the x86 default address or it expects the ACPI to have a > MEM resource. AFAIK ACPI should never rely on hard wired addresses, so > I removed that code in this series. Perhaps tpm_tis should be using > control_area_pa ? Will ACPI ever present a struct resource? (if yes, > why isn't tpm_crb using one?) Is then still a problem. On Martin's system the MSFT0101 device does not have a struct resource attached to it. Does any system, or is this just dead code? Should the control_area_pa be used? Martin: could you try this (along with the other hunk to prevent the oops): Hoping to see it print 0xFED40000 > There is also something wrong with the endianness in the acpi > stuff. I don't see endianness conversions in other acpi places, so I > wonder if the ones in tpm_crb are correct. If they are correct then > the struct needs le/be notations and there are some missing > conversions. I've made a patch to take care of this and move every thing to the include/acpi/actbl2.h definitions, which is why I didn't notice is_fifo in the first place... Jason ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c index 8a3509cb10da..6824a00ba513 100644 --- a/drivers/char/tpm/tpm_tis.c +++ b/drivers/char/tpm/tpm_tis.c @@ -138,6 +138,8 @@ static inline int is_fifo(struct acpi_device *dev) if (le32_to_cpu(tbl->start_method) != TPM2_START_FIFO) return 0; + dev_err(&dev->dev, "control area pa is %x\n", tbl->control_area_pa); + /* TPM 2.0 FIFO */ return 1; }