From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Jiandi An <anjiandi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jarkko Sakkinen
<jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Subject: Re: [PATCH] tpm/tpm_crb: Access locality for non-ACPI and non-SMC start method
Date: Tue, 22 Aug 2017 20:25:26 -0600 [thread overview]
Message-ID: <20170823022526.GA4844@obsidianresearch.com> (raw)
In-Reply-To: <d88e255c-f8c9-b6fc-64bd-8cf56153fcce-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Aug 22, 2017 at 04:28:54PM -0500, Jiandi An wrote:
> I'm sorry perhaps I didn't fully understand the workaround specific to Intel
> PPT. In previous patch thread, you mentioned the following where
> a platform could report to require start method 2 (ACPI start) which is
> sm = ACPI_TPM2_START_METHOD, and actually requires start method 8, which
> is sm = ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD.
I'm also not sure.
To be clear, my desire to see a test that triggers only for the Intel
chips with the problem, and is written in a way that matches exactly
the ACPI data from the broken chip - so things like !CRB are not what
I want to see..
In that light the example I gave was probably not well thought out,
but I also do not understand the exact conditions needed for the Intel
work around either. Hopefully Jarkko can clarify.
Jason
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Jiandi An <anjiandi@codeaurora.org>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
peterhuewe@gmx.de, tpmdd@selhorst.net,
tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tpm/tpm_crb: Access locality for non-ACPI and non-SMC start method
Date: Tue, 22 Aug 2017 20:25:26 -0600 [thread overview]
Message-ID: <20170823022526.GA4844@obsidianresearch.com> (raw)
In-Reply-To: <d88e255c-f8c9-b6fc-64bd-8cf56153fcce@codeaurora.org>
On Tue, Aug 22, 2017 at 04:28:54PM -0500, Jiandi An wrote:
> I'm sorry perhaps I didn't fully understand the workaround specific to Intel
> PPT. In previous patch thread, you mentioned the following where
> a platform could report to require start method 2 (ACPI start) which is
> sm = ACPI_TPM2_START_METHOD, and actually requires start method 8, which
> is sm = ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD.
I'm also not sure.
To be clear, my desire to see a test that triggers only for the Intel
chips with the problem, and is written in a way that matches exactly
the ACPI data from the broken chip - so things like !CRB are not what
I want to see..
In that light the example I gave was probably not well thought out,
but I also do not understand the exact conditions needed for the Intel
work around either. Hopefully Jarkko can clarify.
Jason
next prev parent reply other threads:[~2017-08-23 2:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-18 4:15 [PATCH] tpm/tpm_crb: Access locality for non-ACPI and non-SMC start method Jiandi An
2017-08-19 17:05 ` Jarkko Sakkinen
2017-08-21 3:41 ` Jiandi An
2017-08-22 17:36 ` Jarkko Sakkinen
2017-08-22 17:39 ` Jarkko Sakkinen
2017-08-22 21:28 ` Jiandi An
[not found] ` <d88e255c-f8c9-b6fc-64bd-8cf56153fcce-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-08-23 2:25 ` Jason Gunthorpe [this message]
2017-08-23 2:25 ` Jason Gunthorpe
2017-08-24 12:26 ` Jarkko Sakkinen
2017-08-24 17:20 ` Jiandi An
2017-08-25 16:21 ` Jarkko Sakkinen
2017-08-25 16:21 ` Jarkko Sakkinen
2017-08-25 16:53 ` Jason Gunthorpe
2017-08-25 16:53 ` Jason Gunthorpe
2017-08-25 17:28 ` Jiandi An
2017-08-25 17:28 ` Jiandi An
2017-08-25 17:35 ` Jarkko Sakkinen
2017-08-25 17:35 ` Jarkko Sakkinen
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=20170823022526.GA4844@obsidianresearch.com \
--to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
--cc=anjiandi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=jarkko.sakkinen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.