Re: [PATCH v7 0/4] st33zp24 new architecture proposal and st33zp24 spi driver
Hi Peter, Any news on this patchset ? Best Regards Christophe Le 01/02/2015 22:36, Christophe Ricard a écrit : Hi, The following patchset: - propose a new architecture allowing to share a core st33zp24 data management layer with different phy (i2c & spi). For st33zp24 both phy have a proprietary transport protocol. Both are relying on the TCG TIS protocol. At the end, it simplifies the maintenance. - Add an spi phy allowing to support st33zp24 using with an SPI bus. The complete solution got tested in polling and interrupt mode successfully with i2c & spi phy. This patchset applies on top of Peter's tree https://github.com/PeterHuewe/linux-tpmdd.git for-james branch on top of: d4989d9f693b9502f9288da5db279c2f8c2e50be tpm/tpm_tis: Add missing ifdef CONFIG_ACPI for pnp_acpi_device I confirm also Jarkko Sakkinen's changes are working with this product with both phy's. - v2 takes into account feedbacks from Jason Gunthorpe. - v3 is reduced to 4 patches as 6 out of 10 got accepted for 3.20. Also compare to v2: * Fix build issue with patch v2 04/10 "Replace access to io_lpcpd from struct st33zp24_platform_data to tpm_stm_dev" * Fix link issue with patch v2 08/10 "Split tpm_i2c_tpm_st33 in 2 layers (core + phy)" when building as a module. The symbols wasn't exported in st33zp24.c. * Add missing MODULE_LICENSE in patch v2 09/10 "Add st33zp24 spi phy" * Fix node example in dts spi documentation in patch v2 10/10 "Add dts documentation for st33zp24 spi phy" * Fix typo on Jason Gunthorpe first name. Sorry for that :(... * Change contact email address as tpmsupp...@st.com is no more valid - v4 adds missing module_license in st33zp24 - v5 includes as best as possible PeterHuewe comments. - v6 is more explicit about the spi buffer size and remove their buffer (tx_buf/rx_buf) dynamic allocation - v7 fix scripts/checkpatch.pl error Best Regards Christophe Christophe Ricard (4): tpm/tpm_i2c_stm_st33: Replace access to io_lpcpd from struct st33zp24_platform_data to tpm_stm_dev tpm/tpm_i2c_stm_st33: Split tpm_i2c_tpm_st33 in 2 layers (core + phy) tpm/st33zp24/spi: Add st33zp24 spi phy tpm/st33zp24/dts/st33zp24-spi: Add dts documentation for st33zp24 spi phy .../bindings/security/tpm/st33zp24-spi.txt | 34 + drivers/char/tpm/Kconfig | 11 +- drivers/char/tpm/Makefile | 2 +- drivers/char/tpm/st33zp24/Kconfig | 30 + drivers/char/tpm/st33zp24/Makefile | 12 + drivers/char/tpm/st33zp24/i2c.c| 276 +++ drivers/char/tpm/st33zp24/spi.c| 392 + drivers/char/tpm/st33zp24/st33zp24.c | 688 drivers/char/tpm/st33zp24/st33zp24.h | 37 + drivers/char/tpm/tpm_i2c_stm_st33.c| 911 - include/linux/platform_data/st33zp24.h | 28 + include/linux/platform_data/tpm_stm_st33.h | 39 - 12 files changed, 1499 insertions(+), 961 deletions(-) create mode 100644 Documentation/devicetree/bindings/security/tpm/st33zp24-spi.txt create mode 100644 drivers/char/tpm/st33zp24/Kconfig create mode 100644 drivers/char/tpm/st33zp24/Makefile create mode 100644 drivers/char/tpm/st33zp24/i2c.c create mode 100644 drivers/char/tpm/st33zp24/spi.c create mode 100644 drivers/char/tpm/st33zp24/st33zp24.c create mode 100644 drivers/char/tpm/st33zp24/st33zp24.h delete mode 100644 drivers/char/tpm/tpm_i2c_stm_st33.c create mode 100644 include/linux/platform_data/st33zp24.h delete mode 100644 include/linux/platform_data/tpm_stm_st33.h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
