From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932742AbdBQHUS convert rfc822-to-8bit (ORCPT ); Fri, 17 Feb 2017 02:20:18 -0500 Received: from mout.gmx.net ([212.227.15.15]:50245 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755945AbdBQHUP (ORCPT ); Fri, 17 Feb 2017 02:20:15 -0500 Date: Fri, 17 Feb 2017 08:19:40 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <43990139-3687-60b6-bf1f-77593c3bcd97@gmail.com> References: <1487261306-2494-1-git-send-email-peter.huewe@infineon.com> <1487261306-2494-5-git-send-email-peter.huewe@infineon.com> <43990139-3687-60b6-bf1f-77593c3bcd97@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH 4/5] tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes To: Christophe Ricard , Peter Huewe , Jarkko Sakkinen CC: Jason Gunthorpe , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Christophe Ricard , stable@vger.kernel.org, Alexander Steffen From: Peter Huewe Message-ID: <0FCA4890-55E6-44E2-B88E-EA609A8B698F@gmx.de> X-Provags-ID: V03:K0:Qz2014oO5laru4UjeDga56thuF7RQMCF5IuYLXTHFm6xRgbxp3C gsloJ9Kfb79zCFvJuDLFa8c9GFelFo1qQRDcCC3oDnE668x0vXx0tUxWPGaY6+wIeHBiLhf OvbjQUcFHMHFsu0OlHt9/h4YYW64Po7Zjn0LHHOVzKF2+J06Es82zNSEyrq5ySDV8WDi0Kx OKteu5xbfM4qSaPhCuSTQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Rs6XtbArrIw=:rCppMR4tSUDMWoBDQl59GK ndVMeUIuNncO5h43QekKeUeMCJJk+i2f0d/2rLj3+gwxAGJK5SIZZycsWxIdWPzrPZmQ4LHJC GYfQUqL5BAtZ9QVXxRdhQ6ytv9tNpaqDBu31BfL7Uhf0YEPNqit89ou312AZE+c9oe/0pwkIy 1IZXINVmxRmqW8SxorWkx1uprook4NEP5Q9G8reUTP9Vgbmwikr0aq2z9YjkxhvcLqiTVh8qE mE8jQSacohyTzgr5v8BGOgioMxA/h5Ci8i+Lr/LZU1YZlk2Wbu8M/kSqTDwKaDJB2jdX+8ZDC FryqZz4pkEVLwS7EXxVvcyyFhXLDQ0CfJ+Y/J73rGKd3iY3QoEYdiAAyoFIkgrd3mo9/Moa4U KTQ02rSzntvG/Wom4rJPQDYLi5jOY+Zxz/2gQ9KG7Eti4wjq3Hop6Ub7r862sdIuMLgVkuA1P 4NpVuuDGWM6OdnBDAhNnqZgn7b9wLghp+cpeNof/3KjhCWzWOkFffkoppQomHJEy9LhStfbEe /On7R9bP0agwvCdV2lOAR30R4MNXuzAcCu+HpzccUN7/asGQS0md5AUrfx3qsa1ISDys0JDvw pz1YrtrtpC8dLIbHmQLT3J6VcJTA8SlOWrIEbdn6CsDt8A6uG/H5KKiCUjdK4s0ccCuAirK1n Gt7hHik7Cpmoybw2nlGr+xHYBQ3tZHPWKN/77qigLF2UE0ZcPy+3QJWdVhhNaJKx7nB6T/Pep oUD51C2fzX49bB4ZSfR+oyd75v47QZI+uczZajBIVy88XfkjvjHNkmWzgp+4jJjwLWwPRiV3a tLDgYcw Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 17. Februar 2017 06:11:53 MEZ schrieb Christophe Ricard : >I am not sure i understand here, are you considering there could be >burstcount > 64 with "TCG" TPM ? > With the current upstream version, any command larger with a response of more than 64 byte is broken, since the splitting loop went missing during the merge. At least with our tpms that's the case. (I think we are signalling a higher burstcount value than 64, which is allowed) >Or is this because of TIS vs PTP differences ? > >To be honest, this is a little behind me now :-) > > >On 16/02/2017 08:08, Peter Huewe wrote: >> Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper >> layers, as tpm_tis has no such limitation. Add a loop to hide that >> limitation. >> >> Cc: >> Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") >> Signed-off-by: Alexander Steffen >> Signed-off-by: Peter Huewe >> --- >> drivers/char/tpm/tpm_tis_spi.c | 108 >++++++++++++++++++++++------------------- >> 1 file changed, 57 insertions(+), 51 deletions(-) >> >> diff --git a/drivers/char/tpm/tpm_tis_spi.c >b/drivers/char/tpm/tpm_tis_spi.c >> index 16938e2253d2..b50c5b072df3 100644 >> --- a/drivers/char/tpm/tpm_tis_spi.c >> +++ b/drivers/char/tpm/tpm_tis_spi.c >> @@ -61,68 +61,74 @@ static int tpm_tis_spi_transfer(struct >tpm_tis_data *data, u32 addr, u8 len, >> { >> struct tpm_tis_spi_phy *phy = to_tpm_tis_spi_phy(data); >> int ret; >> - struct spi_message m; >> - struct spi_transfer spi_xfer = { >> - .tx_buf = phy->tx_buf, >> - .rx_buf = phy->rx_buf, >> - .len = 4, >> - .cs_change = 1, >> - }; >> - >> - if (len > MAX_SPI_FRAMESIZE) >> - return -ENOMEM; >> >> - phy->tx_buf[0] = direction | (len - 1); >> - phy->tx_buf[1] = 0xd4; >> - phy->tx_buf[2] = addr >> 8; >> - phy->tx_buf[3] = addr; >> + spi_bus_lock(phy->spi_device->master); >> >> - spi_message_init(&m); >> - spi_message_add_tail(&spi_xfer, &m); >> + while (len) { >> + struct spi_message m; >> + struct spi_transfer spi_xfer = { >> + .tx_buf = phy->tx_buf, >> + .rx_buf = phy->rx_buf, >> + .len = 4, >> + .cs_change = 1, >> + }; >> + u8 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; >> + >> + spi_message_init(&m); >> + spi_message_add_tail(&spi_xfer, &m); >> + ret = spi_sync_locked(phy->spi_device, &m); >> + if (ret < 0) >> + goto exit; >> >> - spi_bus_lock(phy->spi_device->master); >> - ret = spi_sync_locked(phy->spi_device, &m); >> - if (ret < 0) >> - goto exit; >> - >> - if ((phy->rx_buf[3] & 0x01) == 0) { >> - // handle SPI wait states >> - int i; >> - >> - phy->tx_buf[0] = 0; >> - >> - for (i = 0; i < TPM_RETRY; i++) { >> - spi_xfer.len = 1; >> - spi_message_init(&m); >> - spi_message_add_tail(&spi_xfer, &m); >> - ret = spi_sync_locked(phy->spi_device, &m); >> - if (ret < 0) >> + if ((phy->rx_buf[3] & 0x01) == 0) { >> + // handle SPI wait states >> + int i; >> + >> + phy->tx_buf[0] = 0; >> + >> + for (i = 0; i < TPM_RETRY; i++) { >> + spi_xfer.len = 1; >> + spi_message_init(&m); >> + spi_message_add_tail(&spi_xfer, &m); >> + ret = spi_sync_locked(phy->spi_device, &m); >> + if (ret < 0) >> + goto exit; >> + if (phy->rx_buf[0] & 0x01) >> + break; >> + } >> + >> + if (i == TPM_RETRY) { >> + ret = -ETIMEDOUT; >> goto exit; >> - if (phy->rx_buf[0] & 0x01) >> - break; >> + } >> } >> >> - if (i == TPM_RETRY) { >> - ret = -ETIMEDOUT; >> - goto exit; >> + spi_xfer.cs_change = 0; >> + spi_xfer.len = transfer_len; >> + >> + if (direction) { >> + spi_xfer.tx_buf = NULL; >> + spi_xfer.rx_buf = buffer; >> + } else { >> + spi_xfer.tx_buf = buffer; >> + spi_xfer.rx_buf = NULL; >> } >> - } >> >> - spi_xfer.cs_change = 0; >> - spi_xfer.len = len; >> + spi_message_init(&m); >> + spi_message_add_tail(&spi_xfer, &m); >> + ret = spi_sync_locked(phy->spi_device, &m); >> + if (ret < 0) >> + goto exit; >> >> - if (direction) { >> - spi_xfer.tx_buf = NULL; >> - spi_xfer.rx_buf = buffer; >> - } else { >> - spi_xfer.tx_buf = buffer; >> - spi_xfer.rx_buf = NULL; >> + len -= transfer_len; >> + buffer += transfer_len; >> } >> >> - spi_message_init(&m); >> - spi_message_add_tail(&spi_xfer, &m); >> - ret = spi_sync_locked(phy->spi_device, &m); >> - >> exit: >> spi_bus_unlock(phy->spi_device->master); >> return ret; -- Sent from my mobile From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Huewe Subject: Re: [PATCH 4/5] tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes Date: Fri, 17 Feb 2017 08:19:40 +0100 Message-ID: <0FCA4890-55E6-44E2-B88E-EA609A8B698F@gmx.de> References: <1487261306-2494-1-git-send-email-peter.huewe@infineon.com> <1487261306-2494-5-git-send-email-peter.huewe@infineon.com> <43990139-3687-60b6-bf1f-77593c3bcd97@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <43990139-3687-60b6-bf1f-77593c3bcd97-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Christophe Ricard , Peter Huewe , Jarkko Sakkinen Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Christophe Ricard List-Id: tpmdd-devel@lists.sourceforge.net Am 17. Februar 2017 06:11:53 MEZ schrieb Christophe Ricard : >I am not sure i understand here, are you considering there could be >burstcount > 64 with "TCG" TPM ? > With the current upstream version, any command larger with a response of more than 64 byte is broken, since the splitting loop went missing during the merge. At least with our tpms that's the case. (I think we are signalling a higher burstcount value than 64, which is allowed) >Or is this because of TIS vs PTP differences ? > >To be honest, this is a little behind me now :-) > > >On 16/02/2017 08:08, Peter Huewe wrote: >> Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper >> layers, as tpm_tis has no such limitation. Add a loop to hide that >> limitation. >> >> Cc: >> Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") >> Signed-off-by: Alexander Steffen >> Signed-off-by: Peter Huewe >> --- >> drivers/char/tpm/tpm_tis_spi.c | 108 >++++++++++++++++++++++------------------- >> 1 file changed, 57 insertions(+), 51 deletions(-) >> >> diff --git a/drivers/char/tpm/tpm_tis_spi.c >b/drivers/char/tpm/tpm_tis_spi.c >> index 16938e2253d2..b50c5b072df3 100644 >> --- a/drivers/char/tpm/tpm_tis_spi.c >> +++ b/drivers/char/tpm/tpm_tis_spi.c >> @@ -61,68 +61,74 @@ static int tpm_tis_spi_transfer(struct >tpm_tis_data *data, u32 addr, u8 len, >> { >> struct tpm_tis_spi_phy *phy = to_tpm_tis_spi_phy(data); >> int ret; >> - struct spi_message m; >> - struct spi_transfer spi_xfer = { >> - .tx_buf = phy->tx_buf, >> - .rx_buf = phy->rx_buf, >> - .len = 4, >> - .cs_change = 1, >> - }; >> - >> - if (len > MAX_SPI_FRAMESIZE) >> - return -ENOMEM; >> >> - phy->tx_buf[0] = direction | (len - 1); >> - phy->tx_buf[1] = 0xd4; >> - phy->tx_buf[2] = addr >> 8; >> - phy->tx_buf[3] = addr; >> + spi_bus_lock(phy->spi_device->master); >> >> - spi_message_init(&m); >> - spi_message_add_tail(&spi_xfer, &m); >> + while (len) { >> + struct spi_message m; >> + struct spi_transfer spi_xfer = { >> + .tx_buf = phy->tx_buf, >> + .rx_buf = phy->rx_buf, >> + .len = 4, >> + .cs_change = 1, >> + }; >> + u8 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; >> + >> + spi_message_init(&m); >> + spi_message_add_tail(&spi_xfer, &m); >> + ret = spi_sync_locked(phy->spi_device, &m); >> + if (ret < 0) >> + goto exit; >> >> - spi_bus_lock(phy->spi_device->master); >> - ret = spi_sync_locked(phy->spi_device, &m); >> - if (ret < 0) >> - goto exit; >> - >> - if ((phy->rx_buf[3] & 0x01) == 0) { >> - // handle SPI wait states >> - int i; >> - >> - phy->tx_buf[0] = 0; >> - >> - for (i = 0; i < TPM_RETRY; i++) { >> - spi_xfer.len = 1; >> - spi_message_init(&m); >> - spi_message_add_tail(&spi_xfer, &m); >> - ret = spi_sync_locked(phy->spi_device, &m); >> - if (ret < 0) >> + if ((phy->rx_buf[3] & 0x01) == 0) { >> + // handle SPI wait states >> + int i; >> + >> + phy->tx_buf[0] = 0; >> + >> + for (i = 0; i < TPM_RETRY; i++) { >> + spi_xfer.len = 1; >> + spi_message_init(&m); >> + spi_message_add_tail(&spi_xfer, &m); >> + ret = spi_sync_locked(phy->spi_device, &m); >> + if (ret < 0) >> + goto exit; >> + if (phy->rx_buf[0] & 0x01) >> + break; >> + } >> + >> + if (i == TPM_RETRY) { >> + ret = -ETIMEDOUT; >> goto exit; >> - if (phy->rx_buf[0] & 0x01) >> - break; >> + } >> } >> >> - if (i == TPM_RETRY) { >> - ret = -ETIMEDOUT; >> - goto exit; >> + spi_xfer.cs_change = 0; >> + spi_xfer.len = transfer_len; >> + >> + if (direction) { >> + spi_xfer.tx_buf = NULL; >> + spi_xfer.rx_buf = buffer; >> + } else { >> + spi_xfer.tx_buf = buffer; >> + spi_xfer.rx_buf = NULL; >> } >> - } >> >> - spi_xfer.cs_change = 0; >> - spi_xfer.len = len; >> + spi_message_init(&m); >> + spi_message_add_tail(&spi_xfer, &m); >> + ret = spi_sync_locked(phy->spi_device, &m); >> + if (ret < 0) >> + goto exit; >> >> - if (direction) { >> - spi_xfer.tx_buf = NULL; >> - spi_xfer.rx_buf = buffer; >> - } else { >> - spi_xfer.tx_buf = buffer; >> - spi_xfer.rx_buf = NULL; >> + len -= transfer_len; >> + buffer += transfer_len; >> } >> >> - spi_message_init(&m); >> - spi_message_add_tail(&spi_xfer, &m); >> - ret = spi_sync_locked(phy->spi_device, &m); >> - >> exit: >> spi_bus_unlock(phy->spi_device->master); >> return ret; -- Sent from my mobile ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot