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
next prev 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.