Hi Peter,
A TPM command can be up to 2048 byte, A TPM response can be up to 1024 byte.
Between command and response, there are latency byte (up to 15 usually
on st33zp24 2 are enough).
Overall when sending a command and expecting an answer we need in worst
case:
2048 (for the TPM command) + 1024 (for the TPM answer). We need some
latency byte before the answer is available (max 15).
We have 2048 + 1024 + 15.
I will go for a define making the code more readable together with a
comment.
Best Regards
Christophe
Le 28/01/2015 17:48, Peter Huewe a écrit :
Hi Christophe,
sorry to be nitty picky but I still don't get this calculation
+ /* max tpm tx buffer(TPM_BUFSIZE) + max tpm rx buffer(TPM_BUFSIZE / 2)
+ * + MAX_SPI_LATENCY.
+ */
+ phy->spi_xfer.tx_buf = devm_kmalloc(&dev->dev, (TPM_BUFSIZE +
+ (TPM_BUFSIZE / 2) + MAX_SPI_LATENCY),
+ GFP_KERNEL);
+ if (!phy->spi_xfer.tx_buf)
+ return -ENOMEM;
+
+ phy->spi_xfer.rx_buf = devm_kmalloc(&dev->dev, (TPM_BUFSIZE +
+ (TPM_BUFSIZE / 2) + MAX_SPI_LATENCY),
+ GFP_KERNEL);
+ if (!phy->spi_xfer.rx_buf)
+ return -ENOMEM;
and the comment
+ /* max tpm tx buffer(TPM_BUFSIZE) + max tpm rx buffer(TPM_BUFSIZE / 2)
+ * + MAX_SPI_LATENCY.
does not help either.
Why do you define TPM_BUFSIZE as 2048, add TPM_BUFSIZE/2 and something called MAX_SPI_LATENCY to it to use it as your buffer size?
Latency is for me something timing related.
Since you use this TPM_BUFSIZE only in these two lines I'd be happy with either
define which has this magical 2048+2014+15
or (maybe better) add a reasonable comment describing the meaning of this strange calculation.
Thanks,
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
