Re: [PATCH v4 4/7] tpm: tpm_tis: Fix expected bit handling and send all bytes in one shot without last byte in exception

[Jarkko Sakkinen]

On Tue, Mar 31, 2020 at 09:34:28PM +0000, Benoit HOUYERE wrote:
> 
> > On Tue, Mar 31, 2020 at 02:32:04PM +0300, amirmizi6@xxxxxxxxx wrote:
> > > From: Amir Mizinski <amirmizi6@xxxxxxxxx>
> > > 
> > > Today, actual implementation for send massage is not correct. We check 
> > > and loop only on TPM_STS.stsValid bit and next we single check 
> > > TPM_STS.expect bit value.
> > > TPM_STS.expected bit shall be checked in the same time of 
> > > TPM_STS.stsValid, and should be repeated until timeout_A.
> > > To aquire that, "wait_for_tpm_stat" function is modified to 
> > > "wait_for_tpm_stat_result". this function read regulary status 
> > > register and check bit defined by "mask" to reach value defined in "mask_result"
> > > (that way a bit in mask can be checked if reached 1 or 0).
> > > 
> > > Respectively, to send message as defined in 
> > >  TCG_DesignPrinciples_TPM2p0Driver_vp24_pubrev.pdf, all bytes should be 
> > > sent in one shot instead of sending last byte in exception.
> > > 
> > > This improvment was suggested by Benoit Houyere.
> 
> >Use suggested-by tag.
> 
> >Also if something is not correct, please provide a fixes tag.
> 
> > You are speaking now in theoretical level, which we don't really care that much. Is this causing you real issues? If the answer is yes, please report them. If the > >answer is no, we don't need this.
> 
> > /Jarkko
> 
> I2C TPM specification introduce CRC calculation on TPM command bytes.
> CRC calculation take place from last byte acquired to
> TPM_STS.expected bit reset (=0) .It introduces latency and actual
> incorrect implementation becomes visible now under I2C on the contrary
> before that's all.  The case where TPM keeps TPM_STS.expected bit set
> with TPM_STS.stsValid set after last byte reception is possible and is
> not an issue. It's not theoretical level, it's practical level now.

Thank you, think I got it. This means that it does not need a fixes tag
because it does not break any hardware that it currently supported.

I'd suggest refining the commit message. Not only it is somewhat loosely
writte peace of text but also has typos like "massage".

/Jarkko