Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753731AbdCBADb (ORCPT ); Wed, 1 Mar 2017 19:03:31 -0500 Received: from mail-wm0-f45.google.com ([74.125.82.45]:37691 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753691AbdCBAD3 (ORCPT ); Wed, 1 Mar 2017 19:03:29 -0500 MIME-Version: 1.0 In-Reply-To: <20170301231836.GE2820@obsidianresearch.com> References: <20170301115116.19696-1-enric.balletbo@collabora.com> <20170301135429.GF28874@leverpostej> <20170301184333.GA12197@obsidianresearch.com> <20170301231836.GE2820@obsidianresearch.com> From: Sonny Rao Date: Wed, 1 Mar 2017 16:02:51 -0800 X-Google-Sender-Auth: faS1gso92EPJnDwWmmZToqBGz4g Message-ID: Subject: Re: [tpmdd-devel] [PATCH] tpm: do not suspend/resume if power stays on To: Jason Gunthorpe Cc: Mark Rutland , Enric Balletbo i Serra , "linux-kernel@vger.kernel.org" , Rob Herring , tpmdd-devel@lists.sourceforge.net Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1057 Lines: 27 On Wed, Mar 1, 2017 at 3:18 PM, Jason Gunthorpe wrote: > On Wed, Mar 01, 2017 at 02:39:09PM -0800, Sonny Rao wrote: > >> > We recently added global suspend/resume callbacks to the TPM >> > core. Those call backs do not power off the TPM, they just prepare its >> > internal state to loose power to the chip. Skipping that process on >> > hardware that does not power-off the TPM makes sense to me. >> > >> > But, Sonny, perhaps this should be a global flag in tpm_chip, not a >> > per-interface-driver override? >> >> It's a property of the board design not the chip -- maybe I'm >> misunderstanding? > > I mean do not add the code to handle this to tpm_i2c_infineon.c but in > the common chip code instead. > > tpm_i2c_infineon.c should only parse DT properties that are relavent > to the bus that delivers commands to the TPM, things that apply to how > a TPM chip operates should be handled in the core code because they > apply to any command transport bus. Oh right, sorry -- yes this makes perfect sense. > > Jason