Hi Miquèl, > -----Original Message----- > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > Sent: Montag, 18. Juni 2018 10:43 > To: Hecht, Martin (Avnet Silica) <martin.he...@avnet.eu> > Cc: s...@chromium.org; u-boot@lists.denx.de > Subject: Re: [U-Boot] tpm TIS TPMv2.0 > > Hi Martin, > > On Mon, 18 Jun 2018 08:20:20 +0000, "Hecht, Martin (Avnet Silica)" > <martin.he...@avnet.eu> wrote: > > > Hi Miquel, > > > > > -----Original Message----- > > > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > > > Sent: Montag, 18. Juni 2018 10:05 > > > To: Hecht, Martin (Avnet Silica) <martin.he...@avnet.eu> > > > Cc: s...@chromium.org; u-boot@lists.denx.de > > > Subject: Re: [U-Boot] tpm TIS TPMv2.0 > > > > > > Hi Martin, > > > > > > On Fri, 15 Jun 2018 13:34:07 +0000, "Hecht, Martin (Avnet Silica)" > > > <martin.he...@avnet.eu> wrote: > > > > > > > Hi Miquel, Simon, > > > > > > > > Is there any specific reason why the new tpm2_tis_spi_xfer doesn't > > > support full duplex? It seems we did some work in parallel but you > > > sent the patches earlier. Is that codes tested against an existing > > > TPM v2? I have a working implementation what runs on SLB9670 including > full duplex. > > > > > > What do you mean exactly? > > > > > > I don't think the TPM2 protocol makes real use of full-duplex unless > > > for the wait state between the host command and the actual xfer. > > > > You are right, TIS 1.3 FIFO doesn’t use full duplex in physical level. What > > I > mean is that the driver you just wrote doesn't use the xfer function in that > way that you can specify in and out parameters at same time. I did this in my > implementation what gave me an easy chance to control the CS# of the TPM. > > Do you need this CS# handling for more advanced features? Same question > for the in/out xfers? > > > Can you tell me on what TPM did you test? For the SLB9670 the code > > doesn't work on my hardware. > > I tested with a ST33TPHF20 SPI TPM. > > I'm surprised it did not work with an SLB9670, I don't see anything in the > spec > explaining this CS# specificity.
The CS# may controls an internal state machine and the SLB9670 uses that signal. > > > For the code you wrote I'm considering to add a few lines to control > > the CS# in that way how my xfer is doing this for the SLB9670. > > Yes please, share the patch and add me in cc so I could test it with mine. Fine, will do so soon. > > > On the other hand what about to use a xfer what can handle all three > > cases (in, out, in/out)? > > As I did not implement any TPM command that needed it I did not care about > it. Of course if there is a need for it: it should be implemented too. I > contributed only basic support for essential commands (measured boot, > mainly) but please feel free to enhance the code to add more features! > Ok, seems we are working on the same stuff. > Regards, > Miquèl Regards, Martin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot