The documentation says that DMA-safe memory is required for SPI transfers. The I/O buffers passed in by the caller can be allocated anywhere, including on the stack, which is not DMA-safe. So the data needs to be copied to separate, DMA-safe buffers. We did not see any DMA-related issues on our test systems, even without DMA-safe buffers. But this might simply be due to the fact that the SPI transfer size is rather small, so our systems do not bother to set up DMA transfers. Other systems might do so. v2: - Updated commit message with more explanations. v3: - Split into two patches, one for making the buffers DMA-safe and another for using only a single buffer. Alexander Steffen (2): tpm_tis_spi: Use DMA-safe memory for SPI transfers tpm_tis_spi: Use a single buffer for SPI transfers drivers/char/tpm/tpm_tis_spi.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) -- 2.7.4 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
The buffers used as tx_buf/rx_buf in a SPI transfer need to be DMA-safe. This cannot be guaranteed for the buffers passed to tpm_tis_spi_read_bytes and tpm_tis_spi_write_bytes. Therefore, we need to use our own DMA-safe buffer and copy the data to/from it. The buffer needs to be allocated separately, to ensure that it is cacheline-aligned and not shared with other data, so that DMA can work correctly. Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Signed-off-by: Alexander Steffen <Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org> --- drivers/char/tpm/tpm_tis_spi.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c index 88fe72a..05ce841 100644 --- a/drivers/char/tpm/tpm_tis_spi.c +++ b/drivers/char/tpm/tpm_tis_spi.c @@ -47,8 +47,8 @@ struct tpm_tis_spi_phy { struct tpm_tis_data priv; struct spi_device *spi_device; - u8 tx_buf[4]; - u8 rx_buf[4]; + u8 *tx_buf; + u8 *rx_buf; }; static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data *data) @@ -115,10 +115,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (direction) { spi_xfer.tx_buf = NULL; - spi_xfer.rx_buf = buffer; } else { - spi_xfer.tx_buf = buffer; spi_xfer.rx_buf = NULL; + memcpy(phy->tx_buf, buffer, transfer_len); } spi_message_init(&m); @@ -127,6 +126,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (ret < 0) goto exit; + if (direction) + memcpy(buffer, phy->rx_buf, transfer_len); + len -= transfer_len; buffer += transfer_len; } @@ -194,6 +196,14 @@ static int tpm_tis_spi_probe(struct spi_device *dev) phy->spi_device = dev; + phy->tx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); + if (!phy->tx_buf) + return -ENOMEM; + + phy->rx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); + if (!phy->rx_buf) + return -ENOMEM; + return tpm_tis_core_init(&dev->dev, &phy->priv, -1, &tpm_spi_phy_ops, NULL); } -- 2.7.4 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
A single buffer is sufficient for both tx and rx, since bytes that have already been sent are not used anymore and can safely be overwritten with the received bytes. Signed-off-by: Alexander Steffen <Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org> --- drivers/char/tpm/tpm_tis_spi.c | 34 ++++++++++++++-------------------- 1 file changed, 14 insertions(+), 20 deletions(-) diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c index 05ce841..5321245 100644 --- a/drivers/char/tpm/tpm_tis_spi.c +++ b/drivers/char/tpm/tpm_tis_spi.c @@ -46,9 +46,7 @@ struct tpm_tis_spi_phy { struct tpm_tis_data priv; struct spi_device *spi_device; - - u8 *tx_buf; - u8 *rx_buf; + u8 *iobuf; }; static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data *data) @@ -71,14 +69,14 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, while (len) { transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE); - phy->tx_buf[0] = direction | (transfer_len - 1); - phy->tx_buf[1] = 0xd4; - phy->tx_buf[2] = addr >> 8; - phy->tx_buf[3] = addr; + phy->iobuf[0] = direction | (transfer_len - 1); + phy->iobuf[1] = 0xd4; + phy->iobuf[2] = addr >> 8; + phy->iobuf[3] = addr; memset(&spi_xfer, 0, sizeof(spi_xfer)); - spi_xfer.tx_buf = phy->tx_buf; - spi_xfer.rx_buf = phy->rx_buf; + spi_xfer.tx_buf = phy->iobuf; + spi_xfer.rx_buf = phy->iobuf; spi_xfer.len = 4; spi_xfer.cs_change = 1; @@ -88,9 +86,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (ret < 0) goto exit; - if ((phy->rx_buf[3] & 0x01) == 0) { + if ((phy->iobuf[3] & 0x01) == 0) { // handle SPI wait states - phy->tx_buf[0] = 0; + phy->iobuf[0] = 0; for (i = 0; i < TPM_RETRY; i++) { spi_xfer.len = 1; @@ -99,7 +97,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, ret = spi_sync_locked(phy->spi_device, &m); if (ret < 0) goto exit; - if (phy->rx_buf[0] & 0x01) + if (phy->iobuf[0] & 0x01) break; } @@ -117,7 +115,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, spi_xfer.tx_buf = NULL; } else { spi_xfer.rx_buf = NULL; - memcpy(phy->tx_buf, buffer, transfer_len); + memcpy(phy->iobuf, buffer, transfer_len); } spi_message_init(&m); @@ -127,7 +125,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, goto exit; if (direction) - memcpy(buffer, phy->rx_buf, transfer_len); + memcpy(buffer, phy->iobuf, transfer_len); len -= transfer_len; buffer += transfer_len; @@ -196,12 +194,8 @@ static int tpm_tis_spi_probe(struct spi_device *dev) phy->spi_device = dev; - phy->tx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); - if (!phy->tx_buf) - return -ENOMEM; - - phy->rx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); - if (!phy->rx_buf) + phy->iobuf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); + if (!phy->iobuf) return -ENOMEM; return tpm_tis_core_init(&dev->dev, &phy->priv, -1, &tpm_spi_phy_ops, -- 2.7.4 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
On Thu, Aug 24, 2017 at 10:27:44AM +0200, Alexander Steffen wrote:
> The buffers used as tx_buf/rx_buf in a SPI transfer need to be DMA-safe.
> This cannot be guaranteed for the buffers passed to tpm_tis_spi_read_bytes
> and tpm_tis_spi_write_bytes. Therefore, we need to use our own DMA-safe
> buffer and copy the data to/from it.
>
> The buffer needs to be allocated separately, to ensure that it is
> cacheline-aligned and not shared with other data, so that DMA can work
> correctly.
>
> Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alexander Steffen <Alexander.Steffen@infineon.com>
> ---
> drivers/char/tpm/tpm_tis_spi.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c
> index 88fe72a..05ce841 100644
> --- a/drivers/char/tpm/tpm_tis_spi.c
> +++ b/drivers/char/tpm/tpm_tis_spi.c
> @@ -47,8 +47,8 @@ struct tpm_tis_spi_phy {
> struct tpm_tis_data priv;
> struct spi_device *spi_device;
>
> - u8 tx_buf[4];
> - u8 rx_buf[4];
> + u8 *tx_buf;
> + u8 *rx_buf;
> };
>
> static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data *data)
> @@ -115,10 +115,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
>
> if (direction) {
> spi_xfer.tx_buf = NULL;
> - spi_xfer.rx_buf = buffer;
> } else {
> - spi_xfer.tx_buf = buffer;
> spi_xfer.rx_buf = NULL;
> + memcpy(phy->tx_buf, buffer, transfer_len);
> }
>
> spi_message_init(&m);
> @@ -127,6 +126,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len,
> if (ret < 0)
> goto exit;
>
> + if (direction)
> + memcpy(buffer, phy->rx_buf, transfer_len);
> +
> len -= transfer_len;
> buffer += transfer_len;
> }
> @@ -194,6 +196,14 @@ static int tpm_tis_spi_probe(struct spi_device *dev)
>
> phy->spi_device = dev;
>
> + phy->tx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL);
> + if (!phy->tx_buf)
> + return -ENOMEM;
> +
> + phy->rx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL);
> + if (!phy->rx_buf)
> + return -ENOMEM;
> +
> return tpm_tis_core_init(&dev->dev, &phy->priv, -1, &tpm_spi_phy_ops,
> NULL);
> }
> --
> 2.7.4
>
Great. This is much less confusing patch for backporting.
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
/Jarkko
On Thu, Aug 24, 2017 at 10:27:45AM +0200, Alexander Steffen wrote: > A single buffer is sufficient for both tx and rx, since bytes that have > already been sent are not used anymore and can safely be overwritten with > the received bytes. > > Signed-off-by: Alexander Steffen <Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org> > --- > drivers/char/tpm/tpm_tis_spi.c | 34 ++++++++++++++-------------------- > 1 file changed, 14 insertions(+), 20 deletions(-) > > diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c > index 05ce841..5321245 100644 > --- a/drivers/char/tpm/tpm_tis_spi.c > +++ b/drivers/char/tpm/tpm_tis_spi.c > @@ -46,9 +46,7 @@ > struct tpm_tis_spi_phy { > struct tpm_tis_data priv; > struct spi_device *spi_device; > - > - u8 *tx_buf; > - u8 *rx_buf; > + u8 *iobuf; > }; > > static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data *data) > @@ -71,14 +69,14 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, > while (len) { > transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE); > > - phy->tx_buf[0] = direction | (transfer_len - 1); > - phy->tx_buf[1] = 0xd4; > - phy->tx_buf[2] = addr >> 8; > - phy->tx_buf[3] = addr; > + phy->iobuf[0] = direction | (transfer_len - 1); > + phy->iobuf[1] = 0xd4; > + phy->iobuf[2] = addr >> 8; > + phy->iobuf[3] = addr; > > memset(&spi_xfer, 0, sizeof(spi_xfer)); > - spi_xfer.tx_buf = phy->tx_buf; > - spi_xfer.rx_buf = phy->rx_buf; > + spi_xfer.tx_buf = phy->iobuf; > + spi_xfer.rx_buf = phy->iobuf; > spi_xfer.len = 4; > spi_xfer.cs_change = 1; > > @@ -88,9 +86,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, > if (ret < 0) > goto exit; > > - if ((phy->rx_buf[3] & 0x01) == 0) { > + if ((phy->iobuf[3] & 0x01) == 0) { > // handle SPI wait states > - phy->tx_buf[0] = 0; > + phy->iobuf[0] = 0; > > for (i = 0; i < TPM_RETRY; i++) { > spi_xfer.len = 1; > @@ -99,7 +97,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, > ret = spi_sync_locked(phy->spi_device, &m); > if (ret < 0) > goto exit; > - if (phy->rx_buf[0] & 0x01) > + if (phy->iobuf[0] & 0x01) > break; > } > > @@ -117,7 +115,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, > spi_xfer.tx_buf = NULL; > } else { > spi_xfer.rx_buf = NULL; > - memcpy(phy->tx_buf, buffer, transfer_len); > + memcpy(phy->iobuf, buffer, transfer_len); > } > > spi_message_init(&m); > @@ -127,7 +125,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, > goto exit; > > if (direction) > - memcpy(buffer, phy->rx_buf, transfer_len); > + memcpy(buffer, phy->iobuf, transfer_len); > > len -= transfer_len; > buffer += transfer_len; > @@ -196,12 +194,8 @@ static int tpm_tis_spi_probe(struct spi_device *dev) > > phy->spi_device = dev; > > - phy->tx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); > - if (!phy->tx_buf) > - return -ENOMEM; > - > - phy->rx_buf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); > - if (!phy->rx_buf) > + phy->iobuf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); > + if (!phy->iobuf) > return -ENOMEM; > > return tpm_tis_core_init(&dev->dev, &phy->priv, -1, &tpm_spi_phy_ops, > -- > 2.7.4 > Reviewed-by: Jarkko Sakkinen <jarkko.sakkine-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
On Thu, Aug 24, 2017 at 10:27:43AM +0200, Alexander Steffen wrote: > The documentation says that DMA-safe memory is required for SPI transfers. > The I/O buffers passed in by the caller can be allocated anywhere, > including on the stack, which is not DMA-safe. So the data needs to be > copied to separate, DMA-safe buffers. > > We did not see any DMA-related issues on our test systems, even without > DMA-safe buffers. But this might simply be due to the fact that the SPI > transfer size is rather small, so our systems do not bother to set up DMA > transfers. Other systems might do so. > > v2: > - Updated commit message with more explanations. > > v3: > - Split into two patches, one for making the buffers DMA-safe and another > for using only a single buffer. > > Alexander Steffen (2): > tpm_tis_spi: Use DMA-safe memory for SPI transfers > tpm_tis_spi: Use a single buffer for SPI transfers > > drivers/char/tpm/tpm_tis_spi.c | 32 ++++++++++++++++++-------------- > 1 file changed, 18 insertions(+), 14 deletions(-) > > -- > 2.7.4 > Needs to be CC linux-kernel and linux-security-module and tested-by. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> On Thu, Aug 24, 2017 at 10:27:43AM +0200, Alexander Steffen wrote: > > The documentation says that DMA-safe memory is required for SPI > transfers. > > The I/O buffers passed in by the caller can be allocated anywhere, > > including on the stack, which is not DMA-safe. So the data needs to be > > copied to separate, DMA-safe buffers. > > > > We did not see any DMA-related issues on our test systems, even > > without DMA-safe buffers. But this might simply be due to the fact > > that the SPI transfer size is rather small, so our systems do not > > bother to set up DMA transfers. Other systems might do so. > > > > v2: > > - Updated commit message with more explanations. > > > > v3: > > - Split into two patches, one for making the buffers DMA-safe and another > > for using only a single buffer. > > > > Alexander Steffen (2): > > tpm_tis_spi: Use DMA-safe memory for SPI transfers > > tpm_tis_spi: Use a single buffer for SPI transfers > > > > drivers/char/tpm/tpm_tis_spi.c | 32 ++++++++++++++++++-------------- > > 1 file changed, 18 insertions(+), 14 deletions(-) > > > > -- > > 2.7.4 > > > > Needs to be CC linux-kernel and linux-security-module I will resend the patches there. Is this process of what patches to send where documented somewhere? MAINTAINERS mentions only tpmdd-devel. > and tested-by. I forgot to mention that before: Unless otherwise noted, everything that I submit has been tested with: - tpm_tis on x86_64 with LPC TPMs 1.2 and 2.0 (Infineon SLB 9660 and SLB 9665) - tpm_tis_spi on armv7l and aarch64 (Raspberry Pi 2 and 3) with SPI TPMs 1.2 and 2.0 (Infineon SLB 9670) - tpm_i2c_infineon on armv7l (Raspberry Pi 2) with I2C TPMs 1.2 (Infineon SLB 9635 and SLB 9645) Since those tests are fully automated, I'm happy to integrate more TPM chips, if anyone has got some for me ;-) To get some more test coverage for this SPI-specific change, maybe Benoit or Christophe can rerun their tests? Though this change probably depends more on the platform than on the TPM. As far as we could tell from the code, our Raspberry Pis will never use DMA for the SPI transfers to the TPM, because those transfers are too small. Alexander ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Hi Alexander, Obviously, we agree to cover validation with STM TPM to confirm your update. Following my availability, I cannot start it before mid of September. Is it inline with your expectation ? If it's the case, I will start : - tpm_tis_spi on Raspberry PI 3 Next - tpm_tis on X86_64 Could you send me patch file or link to get patch ? By taking Raspberry PI 3 example, How many Byte in SPI transfer size is necessary to use DMA transfer ? Best Regards, Benoit -----Original Message----- From: Alexander.Steffen@infineon.com [mailto:Alexander.Steffen@infineon.com] Sent: mardi 29 août 2017 14:15 To: jarkko.sakkinen@linux.intel.com; Benoit HOUYERE <benoit.houyere@st.com>; Christophe Henri RICARD <christophe-h.ricard@st.com> Cc: tpmdd-devel@lists.sourceforge.net Subject: RE: [PATCH v3 0/2] tpm_tis_spi: Use DMA-safe memory > On Thu, Aug 24, 2017 at 10:27:43AM +0200, Alexander Steffen wrote: > > The documentation says that DMA-safe memory is required for SPI > transfers. > > The I/O buffers passed in by the caller can be allocated anywhere, > > including on the stack, which is not DMA-safe. So the data needs to > > be copied to separate, DMA-safe buffers. > > > > We did not see any DMA-related issues on our test systems, even > > without DMA-safe buffers. But this might simply be due to the fact > > that the SPI transfer size is rather small, so our systems do not > > bother to set up DMA transfers. Other systems might do so. > > > > v2: > > - Updated commit message with more explanations. > > > > v3: > > - Split into two patches, one for making the buffers DMA-safe and another > > for using only a single buffer. > > > > Alexander Steffen (2): > > tpm_tis_spi: Use DMA-safe memory for SPI transfers > > tpm_tis_spi: Use a single buffer for SPI transfers > > > > drivers/char/tpm/tpm_tis_spi.c | 32 > > ++++++++++++++++++-------------- > > 1 file changed, 18 insertions(+), 14 deletions(-) > > > > -- > > 2.7.4 > > > > Needs to be CC linux-kernel and linux-security-module I will resend the patches there. Is this process of what patches to send where documented somewhere? MAINTAINERS mentions only tpmdd-devel. > and tested-by. I forgot to mention that before: Unless otherwise noted, everything that I submit has been tested with: - tpm_tis on x86_64 with LPC TPMs 1.2 and 2.0 (Infineon SLB 9660 and SLB 9665) - tpm_tis_spi on armv7l and aarch64 (Raspberry Pi 2 and 3) with SPI TPMs 1.2 and 2.0 (Infineon SLB 9670) - tpm_i2c_infineon on armv7l (Raspberry Pi 2) with I2C TPMs 1.2 (Infineon SLB 9635 and SLB 9645) Since those tests are fully automated, I'm happy to integrate more TPM chips, if anyone has got some for me ;-) To get some more test coverage for this SPI-specific change, maybe Benoit or Christophe can rerun their tests? Though this change probably depends more on the platform than on the TPM. As far as we could tell from the code, our Raspberry Pis will never use DMA for the SPI transfers to the TPM, because those transfers are too small. Alexander ------------------------------------------------------------------------------ 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 tpmdd-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
On Tue, Aug 29, 2017 at 12:14:37PM +0000, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org wrote: > > On Thu, Aug 24, 2017 at 10:27:43AM +0200, Alexander Steffen wrote: > > > The documentation says that DMA-safe memory is required for SPI > > transfers. > > > The I/O buffers passed in by the caller can be allocated anywhere, > > > including on the stack, which is not DMA-safe. So the data needs to be > > > copied to separate, DMA-safe buffers. > > > > > > We did not see any DMA-related issues on our test systems, even > > > without DMA-safe buffers. But this might simply be due to the fact > > > that the SPI transfer size is rather small, so our systems do not > > > bother to set up DMA transfers. Other systems might do so. > > > > > > v2: > > > - Updated commit message with more explanations. > > > > > > v3: > > > - Split into two patches, one for making the buffers DMA-safe and another > > > for using only a single buffer. > > > > > > Alexander Steffen (2): > > > tpm_tis_spi: Use DMA-safe memory for SPI transfers > > > tpm_tis_spi: Use a single buffer for SPI transfers > > > > > > drivers/char/tpm/tpm_tis_spi.c | 32 ++++++++++++++++++-------------- > > > 1 file changed, 18 insertions(+), 14 deletions(-) > > > > > > -- > > > 2.7.4 > > > > > > > Needs to be CC linux-kernel and linux-security-module > > I will resend the patches there. Is this process of what patches to send where documented somewhere? MAINTAINERS mentions only tpmdd-devel. > > > and tested-by. > > I forgot to mention that before: Unless otherwise noted, everything that I submit has been tested with: > > - tpm_tis on x86_64 with LPC TPMs 1.2 and 2.0 (Infineon SLB 9660 and SLB 9665) > - tpm_tis_spi on armv7l and aarch64 (Raspberry Pi 2 and 3) with SPI TPMs 1.2 and 2.0 (Infineon SLB 9670) > - tpm_i2c_infineon on armv7l (Raspberry Pi 2) with I2C TPMs 1.2 (Infineon SLB 9635 and SLB 9645) > > Since those tests are fully automated, I'm happy to integrate more TPM chips, if anyone has got some for me ;-) > > To get some more test coverage for this SPI-specific change, maybe Benoit or Christophe can rerun their tests? Though this change probably depends more on the platform than on the TPM. As far as we could tell from the code, our Raspberry Pis will never use DMA for the SPI transfers to the TPM, because those transfers are too small. > > Alexander I'll see later if I could peer test tpm_tis_spi with one machine that I have. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> Hi Alexander, > > Obviously, we agree to cover validation with STM TPM to confirm your > update. > Following my availability, I cannot start it before mid of September. Is it inline > with your expectation ? As always, better than nothing, thanks :) > If it's the case, I will start : > - tpm_tis_spi on Raspberry PI 3 > Next > - tpm_tis on X86_64 Those patches only change tpm_tis_spi, so you can skip the tests with tpm_tis. > Could you send me patch file or link to get patch ? Unfortunately, Patchwork is not working anymore, so I'll send you the patches in a separate mail. > By taking Raspberry PI 3 example, How many Byte in SPI transfer size is > necessary to use DMA transfer ? The Raspberry Pi 3 uses drivers/spi/spi-bcm2835.c, which defines BCM2835_SPI_DMA_MIN_LENGTH = 96 bytes. The maximum frame size used by tpm_tis_spi is MAX_SPI_FRAMESIZE = 64 bytes, so the DMA code path is never taken. You could try to set BCM2835_SPI_DMA_MIN_LENGTH to a lower value, to force it to use DMA. > Best Regards, > > Benoit Alexander ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot