Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754792AbcJEPPe (ORCPT ); Wed, 5 Oct 2016 11:15:34 -0400 Received: from mga06.intel.com ([134.134.136.31]:65343 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754487AbcJEPPc (ORCPT ); Wed, 5 Oct 2016 11:15:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,449,1473145200"; d="scan'208";a="1040697083" Date: Wed, 5 Oct 2016 18:15:26 +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: <20161005151526.GA9847@intel.com> References: <20161002101755.GA25844@intel.com> <20161002102455.GA27464@intel.com> <20161002212126.GA25872@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F466B@hasmsx108.ger.corp.intel.com> <20161003124836.GE9990@intel.com> <20161004051946.GA10572@intel.com> <20161004164738.GA17149@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F4C92@hasmsx108.ger.corp.intel.com> <20161004231057.GA20062@obsidianresearch.com> <5B8DA87D05A7694D9FA63FD143655C1B542F5084@hasmsx108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B8DA87D05A7694D9FA63FD143655C1B542F5084@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: 1455 Lines: 36 On Wed, Oct 05, 2016 at 07:48:59AM +0000, Winkler, Tomas wrote: > > > > > > > On Tue, Oct 04, 2016 at 08:19:46AM +0300, Jarkko Sakkinen wrote: > > > > > > > > > > Make the driver uncallable first. The worst race that can happen > > > > > > is that open("/dev/tpm0", ...) returns -EPIPE. I do not consider > > > > > > this fatal at all. > > > > > > > > > > No responses for this reasonable proposal so I'll show what I mean: > > > > > > > > How is this any better than what Thomas proposed? It seems much > > > > worse to me since now we have even more stuff in the wrong order. > > > > > > > > There are three purposes to the ordering as it stands today > > > > 1) To guarantee that tpm2_shutdown is the last command delivered to > > > > the TPM. When it is issued all other ways to access the device > > > > are hard fenced off. > > > > > > I'm not sure where are you taking this requirements from simple bit is > > > just enough to make the HW inaccessible if the interface is designed > > > right. > > > > I'm having a hard time understanding the english in your email. (Jarkko do you > > know what Tomas is talking about??) > > Will try to do better. Jason, sorry your question slipped while going through the dicussion :-) I think I'll take the standpoint that I'll wait for the next version. The important thing is to notice that runtime PM requires the device to be "alive" and in the device hierarchy. It's a constraint... /Jarkko