archive mirror
 help / color / mirror / Atom feed
From: Georges Savoundararadj <>
To: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/,
Subject: Re: About the SLB9670 TPM 2.0 driver status
Date: Thu, 27 Apr 2017 16:36:12 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <4b9a97a8d4164d0b9fa8d8c99618b7fc-nFblLGNE8XKJSz+rYg/>

Hi Alexander,

On 04/27/2017 08:40 AM, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/ wrote:
>> Hi Alexander,
>> On 04/26/2017 09:04 AM, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/ wrote:
>>>> I am working with on Infineon SLB9670 TPM 2.0 on SPI.
>>>> How well is this chip supported in the mainline kernel?
>>> Unfortunately, due to some small bugs, tpm_tis_spi in mainline is not yet
>> compatible with this device. Starting with 4.12 it should be properly
>> supported.
>> Sounds good!
>>>> I am currently using the linux-socfpga kernel (version 4.8.0; branch
>>>> socfpga-4.8) [1]
>>>> on which I applied the following patches from patchwork:
>>>> aacabbe0d5ec tpm_tis_spi: Add small delay after last transfer [2]
>>>> a4a011be786f tpm_tis_spi: Remove limitation of transfers to
>>>> MAX_SPI_FRAMESIZE bytes [3] 840157e08b2f tpm_tis_spi: Check correct
>>>> byte for wait state indicator [4]
>>>> 10cb31aec536 tpm_tis_spi: Abort transfer when too many wait states
>>>> are signaled [5] 3ad7d9172a8c tpm_tis_spi: Use single function to
>>>> transfer data [6] 4a809ec34a0f tpm_tis_core: Choose appropriate
>>>> timeout for reading burstcount [7]
>>>> With these patches, I can read the Vendor ID properly.
>>> Those are all the patches that I needed on a Raspberry Pi 2 for the device to
>> work correctly. I did not use 4.8 though, but worked with 4.10.
>>>> But, the driver initialization fails in the tpm2_probe function.
>>> Could you be more specific? What exactly fails? What data is transferred
>> to/from the TPM when it fails?
>> I tried again on the 4.11-rc8 kernel with the latest patches from linux-tpmdd
>> to be integrated in 4.12 (between tpmdd-next-20170220 and
>> tpmdd-next-20170425) and I got the same failure.
>> The following function calls fails
>> * tpm2_probe
>> ** tpm_transmit_cmd
>> *** tpm_transmit
>> **** chips->ops->send/tpm_tis_send
>> ***** tpm_tis_send_main
>> ****** tpm_tis_send_data
>> tpm_tis_send_data fails at this moment when it checks the status:
>>       status = tpm_tis_status(chip);
>>       if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) {
>>           rc = -EIO;
>>           goto out_err;
>>       }
> Sounds like a communication problem then. The TPM claims to have received less data than necessary for that command, so it did not see some of the bytes that the driver sent.
> The difference between this transfer that fails and the others that you say are successful is the amount of data transferred in a single SPI frame. You could force the driver to split up the data into smaller frames by replacing "burstcnt = min_t(...)" in tpm_tis_send_data with "burstcnt = 1" and see whether this makes a difference. Changing the SPI clock speed might also be worth a try.
> Do you have any other device that can talk to the TPM (maybe a Raspberry Pi 2, since I know those to work)? If so, you can use it first to rule out a general problem with your TPM and then to compare the SPI signals on the line with your other system. We had the problem with a Raspberry Pi 2, that its SPI master under some circumstances generated incorrect signals that the TPM (correctly) did not understand (hence the need for
The driver is now initializing correctly. The problem was related to the 
SPI Slave Select signal.

I am using the SLB9670 TPM 2.0 on a Altera Cyclone V-based board which 
relies for the SPI communication on the  DesignWare SPI controller 
According to the commit 80b444e57948ea4bd5a89fb1f8c404ddab6c1973, this 
controller requires the GPIO Slave Select to be used with the internal 
chip select.

To fix the issue, I had to configure the SPIM0_SS pin as GPIO 
(GENERALIO12(0xFFD084B0)=0) and to add in the device tree the property 
"cs-gpios" as follow:

&spi0 {
         status = "okay";
         cs-gpios = <&portc 2 0>; /* SPI_SS */

         tpm0@0 {
                 reg = <0>;
                 compatible = "infineon,slb9670";
                 spi-max-frequency = <10000000>;



>> The data transferred is the command defined in the tpm2_probe function.
>> Thanks,
>> Georges
>>> Alexander

Check out the vibrant tech community on one of the world's most
engaging tech sites,!

      parent reply	other threads:[~2017-04-27 23:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26  2:12 About the SLB9670 TPM 2.0 driver status Georges Savoundararadj
     [not found] ` <>
2017-04-26 10:37   ` Jarkko Sakkinen
2017-04-26 16:04   ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
     [not found]     ` <a5616ca471a64e5ab4809a231966987b-nFblLGNE8XKJSz+rYg/>
2017-04-26 18:47       ` Georges Savoundararadj
     [not found]         ` <>
2017-04-27 15:40           ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
     [not found]             ` <4b9a97a8d4164d0b9fa8d8c99618b7fc-nFblLGNE8XKJSz+rYg/>
2017-04-27 23:36               ` Georges Savoundararadj [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \
    --cc=Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).