spi/tpm: claim locality just once during boot

All coreboot stages using TPM start with the same sequence: check if
locality is claimed, if so, release it by writing 'active locality'
bit, then try claiming it.

This is actually not a proper procedure: section "5.5.2.3.1 Command
Aborts" of "TCG PC Client Platform TPM Profile (PTP) Specification
Level 00 Revision 00.430 Family 2" lists overwriting active locality
status bit as a means of triggering TPM command abort.

On top of that, none of the coreboot stages releases locality, it is
enough to claim it once when device starts booting.

In fact, locality being active when the device is in verstage is most
likely due to delayed TPM reset processing by the Cr50 TPM: reset is
an asynchronous event, and is processed once current command
processing completes.

The proper procedure is to wait if locality is active until it is
released (which will happen when Cr50 processes reset) and then
proceed to claim it. This needs to happen only during verstage, other
stages using TPM are guaranteed has been claimed earlier.

BRANCH=gru
BUG=b:65867313

TEST=the new autotest triggering EC reset during key generation
     process does not cause boot failures on Fizz device any more.
     Below are times verstage had to wait:

  TPM ready after 3132 ms
  TPM ready after 22120 ms
  TPM ready after 4936 ms
  TPM ready after 6445 ms
  TPM ready after 11798 ms
  TPM ready after 27421 ms
  TPM ready after 4582 ms
  TPM ready after 7532 ms
  TPM ready after 27920 ms
  TPM ready after 3539 ms
  TPM ready after 12557 ms
  TPM ready after 6773 ms
  TPM ready after 1631 ms
  TPM ready after 197 ms
  TPM ready after 24330 ms
  TPM ready after 3241 ms

Change-Id: Iaee04f009bcde03712483e5e03de4a3441ea32b1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/22489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>

0 files changed, 0 insertions, 0 deletions