Re: Aw: [PATCH v5 3/4] tpm/st33zp24/spi: Add st33zp24 spi phy

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html