Am 14. Februar 2017 14:05:11 MEZ schrieb Andrew Lunn <[email protected]>: >> 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.
Sorry I should have read the code before replying. I just remembered that one case we solved a similar issue on a qualcomm master with the same limitation - and limiting the burstcount worked fine for us. >From the code and comments it seems that the tpm does not offer any >continuation or offset mechanism. > >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. As a heads up in my dayjob I do work for Infineon. I did not intend to advertise our tpm, but we have resolved a similar situation. Thanks, Peter > >Thanks > Andrew -- Sent from my mobile ------------------------------------------------------------------------------ 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
