From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFE67C00454 for ; Tue, 10 Dec 2019 21:47:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8262A2073B for ; Tue, 10 Dec 2019 21:47:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="g6B5OOLx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729416AbfLJVr1 (ORCPT ); Tue, 10 Dec 2019 16:47:27 -0500 Received: from mail-yw1-f65.google.com ([209.85.161.65]:42406 "EHLO mail-yw1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728522AbfLJVc1 (ORCPT ); Tue, 10 Dec 2019 16:32:27 -0500 Received: by mail-yw1-f65.google.com with SMTP id w11so7910722ywj.9 for ; Tue, 10 Dec 2019 13:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h2HBW6fWxv/h9l5/xoQmu2icNmaNt5TwBrIw1IUoyYE=; b=g6B5OOLx1gqAh7MPazEsaen/d1R+xGYrL/GP798PFAkHdu2wiunBg2paDTaJceGbIw sWjAhqzIlWpesc2jzY6aw/UcUOvVt5NsNnq5e5nx14owuSFKQofWpCfg2w6HR1MAoE75 POHT/xXoBR0ZoNG9TIoRBuXLUNkFcM17CoMaIUQ7ronNRBjck+pGb7DLuMc6mb6B1NtI 8jPsnuvDw9MVHELMrhN88JxodOUrR/5TOT01shZZF/r2DTFrEzFc84oW6uT2psRiW69/ 3BxRoJPf3C8kfQ0qyaJhUEvaxnmLhLN0lMDuLcLsXbMJVLl66ftLXVSPkwnpmHKtWJS7 M3fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h2HBW6fWxv/h9l5/xoQmu2icNmaNt5TwBrIw1IUoyYE=; b=jSGV3sdkjyNqHTdqb0bhYRbgae+zGNVBUyS+O3ictgxTMhu17K4Hbe6GbNgg4ez2+d Bhk/8hLMuHd2vO83UrLZkjUmq9UV3p7K+eG+4QvFKbfnvWZzSdFl/mErM/hSBjw56Zi9 BW+HElYZ6gPngs3Yw89Aqp6akshfegjR0OGNJPL4YvLs1EVpJPu7sgamHfTmdZjUTlzm lpvGg0eE448e/Y5eVV/QjC0DwdtW5RpX6DzvDFEdZQermBBGF2VXQfTSdVc+iBYVBZ0Z HZDPKhJGNmp4yhMJAdCTIMwkT74AbgPJr3ZL1vqh37orTFoC9CSusAev4nX6VOdM6kib bb+w== X-Gm-Message-State: APjAAAWwwpus4u+SexcNutyXiKwrycjJCvOFi9RP+9DO403qOk3qkWau a8xyAH58WPQN5y6vikshofaT+r7q60axZ3ALc1pu0w== X-Google-Smtp-Source: APXvYqzU6RMVMM/68NdsM1nTuws4x8Fw3keyEjjXcdNrjesF+lar40piLjYGKtCGGC7Q/Fsal1/sIH9aoZP1c8PRrik= X-Received: by 2002:a81:5303:: with SMTP id h3mr26896078ywb.267.1576013546566; Tue, 10 Dec 2019 13:32:26 -0800 (PST) MIME-Version: 1.0 References: <20191210210735.9077-1-sashal@kernel.org> <20191210210735.9077-238-sashal@kernel.org> In-Reply-To: <20191210210735.9077-238-sashal@kernel.org> From: Guenter Roeck Date: Tue, 10 Dec 2019 13:32:15 -0800 Message-ID: Subject: Re: [PATCH AUTOSEL 5.4 277/350] tpm: Add a flag to indicate TPM power is managed by firmware To: Sasha Levin Cc: linux-kernel , "# v4 . 10+" , Stephen Boyd , Andrey Pronin , Duncan Laurie , Jason Gunthorpe , Arnd Bergmann , Greg Kroah-Hartman , Guenter Roeck , Alexander Steffen , Heiko Stuebner , Jarkko Sakkinen , linux-integrity@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 10, 2019 at 1:12 PM Sasha Levin wrote: > > From: Stephen Boyd > > [ Upstream commit 2e2ee5a2db06c4b81315514b01d06fe5644342e9 ] > > On some platforms, the TPM power is managed by firmware and therefore we > don't need to stop the TPM on suspend when going to a light version of > suspend such as S0ix ("freeze" suspend state). Add a chip flag, > TPM_CHIP_FLAG_FIRMWARE_POWER_MANAGED, to indicate this so that certain > platforms can probe for the usage of this light suspend and avoid > touching the TPM state across suspend/resume. > Are the patches needed to support CR50 (which need this patch) going to be applied to v5.4.y as well ? If not, what is the purpose of applying this patch to v5.4.y ? Thanks, Guenter > Cc: Andrey Pronin > Cc: Duncan Laurie > Cc: Jason Gunthorpe > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Cc: Guenter Roeck > Cc: Alexander Steffen > Cc: Heiko Stuebner > Tested-by: Heiko Stuebner > Reviewed-by: Heiko Stuebner > Signed-off-by: Stephen Boyd > Reviewed-by: Jarkko Sakkinen > Signed-off-by: Jarkko Sakkinen > Signed-off-by: Sasha Levin > --- > drivers/char/tpm/tpm-interface.c | 8 +++++++- > drivers/char/tpm/tpm.h | 1 + > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c > index d7a3888ad80f0..7f105490604c8 100644 > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -394,7 +395,11 @@ int tpm_pm_suspend(struct device *dev) > return -ENODEV; > > if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED) > - return 0; > + goto suspended; > + > + if ((chip->flags & TPM_CHIP_FLAG_FIRMWARE_POWER_MANAGED) && > + !pm_suspend_via_firmware()) > + goto suspended; > > if (!tpm_chip_start(chip)) { > if (chip->flags & TPM_CHIP_FLAG_TPM2) > @@ -405,6 +410,7 @@ int tpm_pm_suspend(struct device *dev) > tpm_chip_stop(chip); > } > > +suspended: > return rc; > } > EXPORT_SYMBOL_GPL(tpm_pm_suspend); > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h > index a7fea3e0ca86a..f3bf2f7f755c8 100644 > --- a/drivers/char/tpm/tpm.h > +++ b/drivers/char/tpm/tpm.h > @@ -162,6 +162,7 @@ enum tpm_chip_flags { > TPM_CHIP_FLAG_VIRTUAL = BIT(3), > TPM_CHIP_FLAG_HAVE_TIMEOUTS = BIT(4), > TPM_CHIP_FLAG_ALWAYS_POWERED = BIT(5), > + TPM_CHIP_FLAG_FIRMWARE_POWER_MANAGED = BIT(6), > }; > > #define to_tpm_chip(d) container_of(d, struct tpm_chip, dev) > -- > 2.20.1 >