On Tue, Feb 14, 2017 at 02:05:11PM +0100, Andrew Lunn wrote: > > 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.
Yes, as far as I know, there is no option to do a smaller I2C read, the I2C controller must support large reads. Future reads return the first bytes of the message and I know of no way to offset the read. > 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. FWIW, on all our hardware we design for 2-3 different TPMs because they are a bit difficult to get. There is now a new TCG specification for I2C and SPI connected TPMs, so there may be better choices for compatability. IIRC, our alt for the atmel i2c part is a nuvoton part. Jason ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
