> Hi Alexander, > > > On 04/26/2017 09:04 AM, [email protected] 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 https://patchwork.kernel.org/patch/9600213/). > 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, Slashdot.org! http://sdm.link/slashdot _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
