Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755617AbbLGJw5 (ORCPT ); Mon, 7 Dec 2015 04:52:57 -0500 Received: from dgate20.ts.fujitsu.com ([80.70.172.51]:18582 "EHLO dgate20.ts.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754253AbbLGJw4 (ORCPT ); Mon, 7 Dec 2015 04:52:56 -0500 DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:Received:Received:From:To:CC:Date:Subject: Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version; b=JA3LCuAnZ3SKzEBFsN2NbLe6oZTsiPTXEynCtRKwRvozTRqXe6Vi7hY/ S+v22w18389/qdujS1Sih4u/EYV4kpGtSl7wzd9KY8qbQeB/sV25+7cxP 4aM0GBuIiE534cmlEZtp18/OivBDiBCUERp6Gao2NqwV59GmONzxWDC4V xOcDL9CYJPgIAZHfMex9Awh87WceePaWWtXBqgYY4qadm58p7L71EYBgU JKi/aM/c53T8Jp3VgmJ9+AYQJ1Xl3; X-SBRSScore: None From: "Wilck, Martin" To: Jarkko Sakkinen CC: Jason Gunthorpe , "tpmdd-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" , =?utf-8?B?VXdlIEtsZWluZS1Lw7ZuaWc=?= Date: Mon, 7 Dec 2015 10:52:51 +0100 Subject: Re: [tpmdd-devel] [PATCH v2 0/3] tpm_tis: Clean up force module parameter Thread-Topic: [tpmdd-devel] [PATCH v2 0/3] tpm_tis: Clean up force module parameter Thread-Index: AdEw1Qm8zHn6osadRgi6lnO13GidWg== Message-ID: References: <1448996309-15220-1-git-send-email-jgunthorpe@obsidianresearch.com> <20151201213351.GC5071@intel.com> <20151202182726.GB30972@obsidianresearch.com> <20151202191155.GA2832@obsidianresearch.com> <20151203060042.GB10359@intel.com> <20151203181932.GA22973@obsidianresearch.com> <20151206040226.GA4396@intel.com> <20151206041544.GA5585@intel.com> <20151207085626.GA15567@intel.com> In-Reply-To: <20151207085626.GA15567@intel.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tB79r2SB002836 Content-Length: 1528 Lines: 38 > > > You can completely ignore this question. I saw Martins reply with a fix for > > > "tpm_tis: Use devm_ioremap_resource" that you should squash into that > > > change. So it's proved that TPM ACPI device objects do not always have a > > > memory resource. Good. > > > > Repeat, the memory resource DOES exist on my system. Not sure what proof > > you saw there. > > Ok, lets go this through. > > I deduced this from two facts: > > * It used to have memory resource as conditional and as a fallback use > fixed value. > * Your workaround reverted the situation to this. > > Did I understand something incorrectly? The problem in my case didn't occur because ACPI was lacking a resource. It has one "extra" resource that Jason's original code didn't recognize. Jason's code was wrongly assuming that a resource that isn't of type "IRQ" has to be of type "MEMORY". If I print out the resource types encountered in tpm_check_resource(), I get ACPI_RESOURCE_TYPE_FIXED_MEMORY32 (0x0a) first, followed by ACPI_RESOURCE_TYPE_END_TAG (0x07). The latter was mistakenly used by Jason't code as a memory resource. This is how ACPI ResourceTemplates work (a list with an end marker). The correct solution is to always check the return value of acpi_dev_resource_memory(), as it's currently implemented in Jason't current "for-jarkko" branch. Martin > > /Jarkko ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?