All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Jiandi An <anjiandi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: harba-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [PATCH RFC] tpm_crb: excluding locality registers for ARM64
Date: Mon, 10 Jul 2017 14:29:57 -0600	[thread overview]
Message-ID: <20170710202957.GA19948@obsidianresearch.com> (raw)
In-Reply-To: <8e465692-c445-0f59-5764-9a5ffb4f56f5-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>

On Mon, Jul 10, 2017 at 02:52:34PM -0500, Jiandi An wrote:
> 
> Hi Guys,
> 
> In this patch https://patchwork.kernel.org/patch/9562247/
> Are the locality registers in crb_regs_head specific to x86?

IMHO, the ACPI specification for TPM2 has been a disaster. The spec is
too vauge and weird - this buisness with storing addresses inside a
buffer inside a memory map is insane.

This is allowing implementations to do all manner of crazy things that
make no sense at all.

> The quick fix that would make it work for ARM64 is to also exclude
> CRB_FL_CRB_SMC_START.

Well, when the ACPI extension for ACPI_TPM2_COMMAND_BUFFER_WITH_SMC
was defined, it needs to specify how to handle locality. If it is done
via the registers in crb_regs_head then the ACPI spec needs to define
how to locate those registers.

I suspect the test you pointed out is just poorly constructed:

        if (!(priv->flags & CRB_FL_ACPI_START)) {

It should be

   	if (sm == ACPI_TPM2_COMMAND_BUFFER || sm == ACPI_TPM2_MEMORY_MAPPED)

As those are the only two modes to define the register layout in
this way.

But, you will still need to implement locality support for
ACPI_TPM2_COMMAND_BUFFER_WITH_SMC.

> For example, in crb_map_io(),  there is a specific PTT HW bug workaround for
> x86.
> 
> 	/*
> 	 * PTT HW bug w/a: wake up the device to access
> 	 * possibly not retained registers.
> 	 */
> 	ret = crb_cmd_ready(dev, priv);
> 	if (ret)
> 		return ret;
> 
> crb_cmd_ready() does nothing for devices with ACPI-start method as it does
> not support goIdle and cmdReady bits and idle state management is not
> exposed to the host SW.  So I've done similar workaround to bypass by
> additionally excluding CRB_FL_CRB_SMC_START.

Again, I think these tests are backwards, a work around like this
should be a while list, not a black list.. So it should refer to
exactly the sm values the impacted chipsets would use.

Jason

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

  parent reply	other threads:[~2017-07-10 20:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10 19:52 [PATCH RFC] tpm_crb: excluding locality registers for ARM64 Jiandi An
     [not found] ` <8e465692-c445-0f59-5764-9a5ffb4f56f5-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-07-10 20:29   ` Jason Gunthorpe [this message]
     [not found]     ` <20170710202957.GA19948-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2017-07-16 11:16       ` 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=20170710202957.GA19948@obsidianresearch.com \
    --to=jgunthorpe-epgobjl8dl3ta4ec/59zmfatqe2ktcn/@public.gmane.org \
    --cc=anjiandi-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=harba-sgV2jX0FEOL9JmXXK+q4OQ@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.