Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758045AbcJHKr7 (ORCPT ); Sat, 8 Oct 2016 06:47:59 -0400 Received: from mga06.intel.com ([134.134.136.31]:1380 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756068AbcJHKrx (ORCPT ); Sat, 8 Oct 2016 06:47:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,460,1473145200"; d="scan'208";a="770297644" Date: Sat, 8 Oct 2016 13:47:38 +0300 From: Jarkko Sakkinen To: "Winkler, Tomas" Cc: Jason Gunthorpe , "tpmdd-devel@lists.sourceforge.net" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] tpm: don't destroy chip device prematurely Message-ID: <20161008104738.GA6825@intel.com> References: <20161004164738.GA17149@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F4C92@hasmsx108.ger.corp.intel.com> <20161004231057.GA20062@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F5084@hasmsx108.ger.corp.intel.com> <20161005171132.GE18636@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F54E9@hasmsx108.ger.corp.intel.com> <20161005211656.GA20920@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F561B@hasmsx108.ger.corp.intel.com> <20161006020748.GA17479@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F625A@hasmsx108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B542F625A@hasmsx108.ger.corp.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 636 Lines: 13 On Fri, Oct 07, 2016 at 02:24:59PM +0000, Winkler, Tomas wrote: > So here I'm to say I'm sorry for misleading this, after all the > doubts I got back to debugging and traces. One thing for a reason > moving the device_del, had really made the problem go away, but the > real problem was unbalance runtime_pm PUT/GET from the tpm_crb probe > function. I will post the fixed patch, of course, this one should be > dropped. In any case, and this is not just to keep my ego up, that > calling to the tom stack with unutilized dev is not healthy and we > should look for that. Great. I'll test the fix once it's available. /Jarkko