All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
To: Peter Huewe <peterhuewe-Mmb7MZpHnFY@public.gmane.org>
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: Atmel I2C TPM transfer length issues
Date: Tue, 14 Feb 2017 14:05:11 +0100	[thread overview]
Message-ID: <20170214130511.GA32480@lunn.ch> (raw)
In-Reply-To: <A6C9A409-4FF4-41A7-AE4F-0727B1464447-Mmb7MZpHnFY@public.gmane.org>

> Just limit the value which get_burstcount() returns to 256.
>
> This should do the trick - because that would be the mechanism the
> tpm itself would use to fragment its response.  Atleast for other
> tpms like our infineon slb9645 i2c tpm that would work.

Yes, that was one idea i had. But then i found the comment on the top
of tpm_i2c_atmel:

 * Teddy Reed determined the basic I2C command flow, unlike other I2C TPM
 * devices the raw TCG formatted TPM command data is written via I2C and then
 * raw TCG formatted TPM command data is returned via I2C.

The driver does not do anything like read the burst size and then
transfer in blocks. It reads/writes all in one go.

However, you have answered what was going to be a follow question. The
hardware is not yet set in stone. We could change the TPM. Use the
Infinion TPM with a modified get_burstcount(). And you think this will
work. Great.

Thanks
	Andrew

------------------------------------------------------------------------------
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-02-14 13:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-14  2:33 Atmel I2C TPM transfer length issues Andrew Lunn
     [not found] ` <20170214023336.GC21340-g2DYL2Zd6BY@public.gmane.org>
2017-02-14  8:39   ` Peter Huewe
     [not found]     ` <A6C9A409-4FF4-41A7-AE4F-0727B1464447-Mmb7MZpHnFY@public.gmane.org>
2017-02-14 13:05       ` Andrew Lunn [this message]
     [not found]         ` <20170214130511.GA32480-g2DYL2Zd6BY@public.gmane.org>
2017-02-14 14:06           ` Peter Huewe
2017-02-14 17:37           ` Jason Gunthorpe

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=20170214130511.GA32480@lunn.ch \
    --to=andrew-g2dyl2zd6by@public.gmane.org \
    --cc=peterhuewe-Mmb7MZpHnFY@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.