From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Peter.Huewe@infineon.com
Cc: linux-kernel@vger.kernel.org, tpmdd-devel@lists.sourceforge.net
Subject: Re: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started
Date: Mon, 1 Oct 2012 10:15:36 -0600 [thread overview]
Message-ID: <20121001161536.GC31620@obsidianresearch.com> (raw)
In-Reply-To: <74A44E99E3274B4CB570415926B37D440EAA91@MUCSE501.eu.infineon.com>
On Mon, Oct 01, 2012 at 09:17:28AM +0000, Peter.Huewe@infineon.com wrote:
> Hi Jason,
>
> > The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
> > TPM_STARTUP has not been issued. This will result in the TPM driver
> > failing to load and no way to recover. Detect this and automatically
> > issue TPM_STARTUP.
>
> > This is for embedded applications where the kernel is the first thing
> > to touch the TPM.
>
> Thanks for working on this.
> I also thought about this scenario quite often.
>
> Shouldn't we then also add a TpmStartup(ST_STATE) in case of a resume?
> rc=GetCapability()
> if(rc==INVALID_POSTINIT)
> tpm_transmit ("TPM_STARTUP(ST_STATE)")...
I'm not familiar enough with how the power management flow works with
the TPM to do this. I don't think that can be the general case
because:
3. If stType = TPM_ST_STATE
a. If the TPM has no state to restore, the TPM MUST set the internal
state such that it returns TPM_FAILEDSELFTEST to all subsequent
commands.
So you need to know a save state exists in the TPM before attempting
the command?
Would you agree that CLEAR is appropriate for an initial driver
attach on probe?
Jason
next prev parent reply other threads:[~2012-10-01 16:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-30 23:30 [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started Jason Gunthorpe
2012-10-01 9:17 ` [tpmdd-devel] " Peter.Huewe
2012-10-01 16:15 ` Jason Gunthorpe [this message]
2012-10-01 17:10 ` Kent Yoder
2012-10-01 17:39 ` Jason Gunthorpe
2012-10-04 17:41 ` Kent Yoder
2012-10-04 18:02 ` Jason Gunthorpe
2012-10-08 7:09 ` Peter.Huewe
2012-11-21 7:10 ` [PATCH resend] " Jason Gunthorpe
2012-11-21 8:59 ` Peter.Huewe
2012-11-21 17:29 ` Jason Gunthorpe
2012-11-21 17:37 ` Peter.Huewe
2012-11-21 18:37 ` [PATCH v4] " Jason Gunthorpe
2012-11-21 20:17 ` Peter Hüwe
2012-11-21 20:12 ` Jason Gunthorpe
2012-11-21 20:54 ` [PATCH v5] " Jason Gunthorpe
2012-11-26 20:08 ` Kent Yoder
2012-10-01 15:14 ` [PATCH] " Kent Yoder
[not found] <4347_1349050738_q910IviQ005340_20120930233012.GH30637@obsidianresearch.com>
2012-10-01 12:57 ` [tpmdd-devel] " Jonathan McCune
2012-10-01 15:15 ` Peter.Huewe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121001161536.GC31620@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=Peter.Huewe@infineon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tpmdd-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).